Certified Administrator

Security & Access
List the information captured on the User Record
Delegated Approver
Time Zone
Admin Newsletter
Offline user
Sales Anywhere User
Accessibility Mode
Send Apex Warning Emails
Development Mode
Allow Forecasting
Checkout Enabled
Call Center
Email Encoding
Employee Number
Used Space
Last Login
Create and maintain User Records
Setup –> Manage Users –> Users
An user cannot be deleted. When needed a user needs to be logically deleted ( elaves an org) then transfer all objects ( ownership gets transferred) and set the user to inactive ( by unclicking the 'active' button). THis leaves the historic records with that users name, and hence maintains data integrity.
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
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.
Resolution has a flexible sharing model. As the System Administrator, you can define the default sharing model for your organization in order to give users greater access to information. The four sharing model options can be selected separately for Leads, Contacts, Accounts, Assets and Contracts, Opportunities, Cases, and the group Calendar. These options include:

This setting for a given object allows users to access only the data they own. No one will be able to view records owned by others.

This setting allows users to see, but not change, records in their organization, regardless of who owns those items. Items can also be added by anyone onto related lists with this permission level.

This setting allows all users the ability to view and edit records owned by others. But ownership itself cannot be changed except by the owner.

This setting on an object allows all users the ability to view, edit, and even change ownership of records owned by others.

To change your Organization Wide Default Security & Access rules:

1. Click on: Setup | Administration Setup | Security Controls | Sharing Rules

2. Click on "Edit" for the Organization Wide Defaults

3. Choose the default access level for each object

4. Click "Save"
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:


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:

Security controls- does the user’s profile have access to this object?
If no, deny access.
Is Grant Access Using Hierarchies enabled for this object?
If No –> Step 3
If Yes –>
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)
Grant permissions of any sharing rule specific to my role
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.
Build a Role Hierarchy
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

You can also share records from custom objects

To view a custom object record: “Read” on the custom object
Custom Objects
Build Sharing Rules
Security Controls –> Sharing Settings

Sharing rules can be established between:

Public Groups
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:
List the places to use Folders
Email Templates
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)

Another difference is that role hierarchies do not apply when evaluating access to a Folder. It is strictly to the role, only.

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.

© Copyright Contact | Site Map