ForceCertified.com

List the information captured on the User Record

• Name
• Alias
• Email
• Username
• Delegated Approver
• Manager
• Title
• Company
• Department
• Division
• Address
• Time Zone
• Locale
• Language
• Newsletter
• Admin Newsletter
• Role
• Profile
• Active
• Offline user
• Sales Anywhere User
• Accessibility Mode
• Send Apex Warning Emails
• Development Mode
• Allow Forecasting
• Checkout Enabled
• Call Center
• Phone
• Extension
• Fax
• Mobile
• Email Encoding
• Employee Number
• Used Space
• Last Login

Related Lists

• Personal Groups
• Public Group Membership
• Queue Membership
• Managers in Role Hierarchy
• Login History

 

Create and maintain User Records

Setup –> Manage Users –> Users

 

Explain the Record Owner concept

For each and every record there is one and only one record owner.  Records can only be assigned to active licensed Salesforce users.  When a user is marked inactive, they still own all records assigned to them, but cannot be assigned new records.  The terminology “record owner” is reflected through Salesforce.  For instance, the “My Opportunities” list view refers to “opportunity records in which I am listed as the record owner”.

Additionally, the role of the record owner is what determines access to that record for the rest of the organization via Sharing Settings.  Synchronization applications (Connect for Outlook, Salesforce Offline) will only synchronize records owned by the user by default (two exceptions: sharing groups, if a user owns an account, they will automatically collect all of the contacts regardless of owner).

In practice each user should be responsible for all records owned.  For instance, sales rep X owns account ABC Finance.  Rep X would be responsible for keeping all address information, contacts, and opportunities up to date.

 

Describe the elements of the Sharing model

See “Overview of Data Permissions Setup”

Sharing Settings control the default access for each object across the organization.  Sharing rules per object can grant access beyond the default Sharing Settings; they cannot restrict access.

Default Sharing Settings

See “Sharing Model Fields”

• Controlled by Parent
• Private
• Public Read Only
• Public Read/Write
• Public Read/Write/Transfer
• Public Full Access (campaigns only)

Grant Access Using Hierarchies is cannot be disabled for standard objects.  When this setting is enabled, the role of the record owner determines visibility throughout the organization.  Users in roles higher in the hierarchy will be always have full access (view/edit/delete) to all records owned by those lower in hierarchy.

If Grant Access Using Hierarchies is not enabled, all roles are treated equally regardless of hierarchy.

 

Describe the scope and capabilities of Organization-Wide Defaults

Organization-wide defaults control the level of access each user has to record they do not own.  Let’s examine my example:

Roles:

• C-Level & E-Level Management
  • Sales Management
    • Sales Reps
  • Operations Management
    • Operations Dispatchers
  • Customer Service Management
    • Customer Service Reps

Sharing Settings for Opportunity are set to “Private”.  A Sharing Rule exists that grants Operations Dispatchers Read Access to Sales Reps’ opportunities.  Here’s how this would play out.  We’re looking at access to Sales Reps’ opportunities:

C-Level & E-Level Management	Full Access (hierarchy)
Sales Management	Full Access (hierarchy)
Sales Reps	No Access
Operations Management	Read Access (granted by hierarchy)
Operations Dispatcher	Read Access (granted by sharing rule)
Customer Service Management	No Access
Customer Service Reps	No Access

Notice how even sharing rules are affected by Grant Access Using Hierarchies.  Note: Group-based sharing rules do not propagate using hierarchies.

Explain how access is granted through the Role Hierarchy

When a user accesses a record they do not own, the following takes place:

1. Security controls- does the user’s profile have access to this object?
   If no, deny access.
2. Is Grant Access Using Hierarchies enabled for this object?
   If No –> Step 3 
   If Yes –>
   1. Is this user’s role higher in the hierarchy than the role of the record’s owner?
      If Yes –> Provide full access
      If No –> Grant permissions of any sharing rule for users lower in the hierarchy (see above example)
3. Grant permissions of any sharing rule specific to my role
4. Grant permissions of default sharing settings

Grant the highest privileges of all of these steps combined.

Note: sharing rules only control access to the object.  Field level accessibility is not

 

Set up Organization-Wide Defaults

Security Controls –> Sharing Settings

 

Describe the use of Roles

Roles are a principal element in sharing rules.  Users should be grouped into roles based upon their need for access to data- how they fit into the role hierarchy.  Creating a role for each title is not required.  Roles are accessed throughout the application, and are particularly important for reporting.  For instance, if you have two groups “Outside Sales” and “Inside Sales” you can run comparative reports to both roles.

Build a Role Hierarchy

Manage Users –> Roles

Roles report to another role.  It is a one-to-many hierarchical relationship.

 

Assign Users to Roles

Manage Users –> Roles

 

Mass-transfer records from one user to another

Data Management –> Mass Transfer Records

Select the type of record to transfer.  Enter the old user, new user, and set the filter criteria for records to transfer.  It is essentially the s
ame as running a report but instead of getting results you transfer the record.

 

List the objects that may have Sharing Rules

• Lead
• Account
• Contact
• Opportunity
• Case
• Campaign
• Custom Objects

 

Build Sharing Rules

Security Controls –> Sharing Settings

Sharing rules can be established between:

• Public Groups
• Queues
• Roles
• Roles and Subordinates

 

Share records manually

Note: The sharing button will only appear when a record the Sharing Model for the object is either Private or Read Only.  In my developer test account, no objects by default qualified.

Click on the record, click Sharing.  Select the users/groups and access level to grant.  Records are shared as such individually.

 

Describe the use cases of Public Groups and where to use them

Public Groups are created by administrators and can be used by everyone; they have the same basic functionality as private groups.  A few uses include using a sharing rule (org-wide or record sharing), specify contact synchronization, and add multiple users to a Salesforce Content workspace.

 

Compare and contrast Sales with Account teams

Both are Enterprise+ (Enterprise and higher editions only; this includes developer).

Sales Teams are designed to share information and establish roles between different roles within the organization.  For instance, a Sales Rep, CSR, and Account Executive are all working on the same account.  The owner of the opportunity can create roles for each of the others and provide write access to the opportunity:

 

Account Teams work on the same principal, however they can share all information on the account:

 

List the places to use Folders

• Documents
• Email Templates
• Reports
• Dashboards

 

Describe how Folder access differs from Record access

Folders act as containers for records.  Folders are only available for certain object (reports, dashboards, documents, email templates).  Creating a folder will let you specify the organization’s access to that folder and the records within.  Creating a folder has the following options:

Public Folder Access (Read only or Read/Write)

Selection of default access (This folder is accessible by all users, including portal users; This folder is hidden from all users; This folder is accessible only by the following users:)

 

Create Folders to organize and provide access to data

Click edit or create new on a folder list view.