Salesforce Admin Certification - Security

Front 1

Explain the concept of record ownership.

Back 1

Every record in Salesforce must have an owner. Records can be owned by either users or queues. By default, the user that creates the record is the owner. Record owner is typically used to determine responsibilities (e.g. I manage the leads that I own), reporting (I am credited for the opportunities that I own), record security, and for a variety of other purposes.

Front 2

Describe the capabilities of the User Sharing feature.

Back 2

User Sharing allows an administrator to set the user object org-wide default (OWD) to private. This feature is enabled by default for orgs created after the Winter 14 Release.

Front 3

Describe how access to data and functionality is structured within Salesforce.

Back 3

Organization Security: When (Login Hours), where (Login IP Ranges), and how (UI/API/etc.) a user can login.

Object Security: What actions a user can take on the records of a particular object (in conjunction with record security).

Record Security: What actions a user can take on an existing record (in conjunction with object security).

Field-Level Security: Determines which fields a user can view and update for each object.

Folder Security: Determines access to a variety of information including reports, dashboards, email templates, and more.

Front 4

Explain who can delete records in Salesforce.

Back 4

To delete a record, the user must have the "Delete" object permission (profile or permission set) and "Full Access" to the record. "Full Access" is typically granted to the record owner, users higher in the role hierarchy than the record owner, and system administrators.

Front 5

Describe profiles and their influence on security.

Back 5

Each user is assigned a one profile, which is instrumental in determining a user’s functional access (apps, tabs, object-level permissions), how information is displayed to the user(page layouts, record types, field-level security), and a wide range of other permissions.

Front 6

List and describe the standard profiles.

Back 6

Ensure that you understand the Salesforce license standard profiles:
Contract Manager
Marketing User
Read Only
Solution Manager
Standard User
System Administrator

Front 7

Explain when to create a custom profile.

Back 7

As customization of standard profiles is limited, create custom profiles prior to assigning users to profiles.

Front 8

Describe permission sets, and common use cases where they are appropriate.

Back 8

Whereas the profile is used to set the foundation for a user's privileges, permission sets are optionally used to extend a user's privileges.

Permission sets can drastically reduce the number of custom profiles required in an org.

Two common use cases:

1. One-off cases where a user needs privileges not granted by their profile (e.g. extending the delete leads permission to one inside sales team, while the rest of the team cannot delete leads).

2. Extending privileges to users that are assigned different profiles (e.g. access to a 3rd party application).

Front 9

Describe how Organization-Wide Defaults (OWDs) influence security.

Back 9

Organization-wide default settings determine the default record-level permissions granted to all users for all records within each object. For instance, setting the Account object to "Public Read/Write" will ensure that all users have "Read/Write" record-level permissions to all account records.

The most commonly used settings are:
Private: No record access granted
Public Read Only: Read only record access granted
Public Read/Write: Read/Write record access granted
Public Read/Write/Transfer (Cases, Leads): Full record access granted
Controlled by Parents (Contacts, Activities): Parent record controls access

Front 10

Describe roles and their influence on security.

Back 10

A user's role sets the foundation for what records and folders they can access. Users are granted full access to records owned by users in subordinate roles on objects where "Grant Access Using Hierarchies" is enabled.

Front 11

Describe groups and their influence on security.

Back 11

Public groups are used to streamline the process of sharing access to records and folders. A group is compromised of users, roles, and other groups.

Front 12

Describe sharing rules, and when their usage is appropriate.

Back 12

Sharing rules are used to extend record access to users within specified roles or groups.

Records can be shared either based on record owner (role, group) or record criteria (known as a criteria-based sharing rule; e.g. all accounts in state "OH").

Sharing rules can extend either Read Only or Read/Write access.

Front 13

Describe a queue's influence on security.

Back 13

Ensure that you understand the fundamentals of queues - see User Setup & Login Process – Free for more.

When a user is a member of a queue and a record is owned by a queue, then the user will inherit "Full Access" to that record.

Front 14

Explain how manual sharing can be used to extend record access.

Back 14

Users can manually share access to records that they own with other users, roles, and groups.

Front 15

Describe delegated administration.

Back 15

Whereas profiles and permission sets grant the ability to administer all users and objects, delegated administration allows administration of only specified users (based on roles/profiles) and specified custom objects.

Front 16

Describe the resources to monitor Salesforce system performance and security.

Back 16

Use trust.salesforce.com to monitor system and security status, as well find best practices from Salesforce.

Front 17

What is manual record sharing?

Back 17

By clicking “Sharing”, a user can manually share access to this record with other groups, roles, and users. The user must first have “Full Access” to the record.

Front 18

How do you view who has access to a particular record and it's related information and records?

Back 18

On the desired record, click 'Sharing' then 'Expand List'. You can click 'Why?' next to a user's name to see the reason the user has access to the record.

Front 19

What is Delegated Administration?

Back 19

Delegated administration allows named users to manage other users within selected roles and profiles, as well as manage fields on selected custom objects.Correct – a delegated admin cannot manage the FIELDS on a standard object. A delegated administrator cannot be delegate admin for system administrator bc system admin has more rights.

Front 20

Why use Delegated Administration?

Back 20

Delegated administration allows you to specify which users (based on role/profile) and custom objects (standard objects excluded) a delegated administrator can manage.

Front 21

What is trust.salesforce.com?

Back 21

Trust.salesforce.com is the salesforce.com community's home for real-time information on system performance and security.

Front 22

When can you log in as another user? How?

Back 22

If you are system administrator, you can log in as another user. Go to Users then click the 'Login' link next to the user's name.

Front 23

What is a group?

Back 23

A group is comprised of users, roles, and other groups. There are two types of groups: Public groups and personal groups.

Front 24

What is a public group?

Back 24

Public groups are created and maintained by administrators, and can be referenced in org-wide configuration (such as sharing rules).

Front 25

What is a personal group?

Back 25

Personal groups are created and maintained by users, and can only be referenced in select configuration (such as Outlook contact synchronization).

Front 26

Why use public groups?

Back 26

Use public groups to streamline the process of sharing access to records and folders with a collection of users.

Front 27

When would you use public groups?

Back 27

1. Sharing access to records or folders with named users

2. Sharing access to several resources to the same collection of users within specified roles. (You could configure the sharing criteria for multiple folders, or create a public group with the roles, and share access to each folder with the group.)

Front 28

Name 2 important considerations when creating and using groups.

Back 28

1. There is no way to monitor where groups are referenced (e.g. you have to view each individual report folder, sharing rules, etc.). For this reason, make sure to have a clear documentation and usage strategy for groups (or at a minimum, a very clear naming convention).
2. When groups are referenced in sharing rules, “Grant Access Using Hierarchies” can be extended to group access.

Front 29

What is the role hierarchy?

Back 29

The role hierarchy provides a framework to structure access to records and folders in your organization.

Front 30

What is the significance of a user’s role?

Back 30

Each user is assigned one role, which sets the foundation for their access to records and folders.

Front 31

What is “Grant Access Using Hierarchies”?

Back 31

“Grant Access Using Hierarchies” is a setting for configuring organization-wide defaults (Setup –> Security Controls –> Sharing Settings). For most standard objects, the option is always enabled. For custom objects, it is enabled by default but can be disabled.

Users are granted full access (create, read, edit, delete) record-level permissions to the records meeting both criteria:

* The record is owned by a user in a subordinate role.
* The object has “Grant Access Using Hierarchies” enabled.

Front 32

What is a permission set?

Back 32

Permission sets are optionally assigned to a user to grant them privileges in addition to their profile.

Front 33

Why use permission sets?

Back 33

Using permission sets effectively can help you reduce the number of profiles needed in your Salesforce org, which can dramatically reduce administrative overhead in some scenarios.

Front 34

When is the use of permission sets appropriate?

Back 34

Use the profile to set the foundation for a user’s privileges. Then use permission sets to grant additional privileges for one-off cases, or instances where the same set of privileges must be granted for users that are assigned to different profiles (e.g. providing access to a 3rd party application shared by several departments).

Front 35

Describe a scenario in which it would be appropriate to use permission sets.

Back 35

1) Your standard profile of Inside Sales Rep may not include the ability to delete leads, but you have one sales rep who needs to be able to delete leads. Instead of creating a new customer profile just for this sales rep, you can create a permission set (ie "Delete leads") and add this permission set to her user record in order to give her this ability while the other Inside Sales Rep profiles will not have that ability.

2) Your organization has an application to track job applicants, which multiple departments will be using. If you were using just profiles, you would have to create a new one for each user by cloning the existing assigned profile and then adding the required privileges. Instead, you could create a single permission set that grants the appropriate privileges and grant that permission set to each user as needed.

Front 36

Can permission sets grant and revoke privileges?

Back 36

No, permission sets can only grant, NOT revoke, privileges. You can remove the permission set to revoke that access that permission set gave.

Front 37

Are permission sets optional?

Back 37

Yes, permission sets are optional

Front 38

Can a user be assigned more than 1 permission set?

Back 38

A user is assigned 0 to many permission sets.

Front 39

Does the profile control elements that a permission set cannot influence?

Back 39

Yes, the profile controls some elements such as the page layout assignment that a permission set cannot influence.

Front 40

What is a profile?

Back 40

A profile is a collection of permissions and settings that is instrumental in determining a user’s functional access (apps, tabs, object-level permissions), how information is displayed to the user (page layouts, record types, field-level security), and a wide range of other permissions.

Front 41

True/false: Each user must be assigned one profile.

Back 41

TRUE: Each user must be assigned one profile.

Front 42

What’s the difference between standard and custom profiles?

Back 42

Standard profiles are included with Salesforce. Object-level and user permissions cannot be changed on these profiles. Standard profiles cannot be deleted.

Custom profiles are created by an administrator and can be fully customized. Custom profiles can be deleted.

Front 43

When should I create custom profiles?

Back 43

Generally speaking you’ll want to create custom profiles prior to assigning users to profiles. As you have limited ability to change standard profiles, it is generally a best practice to assign all users (with the exception of the system administrator) to custom profiles, in case you have to make changes to the profile later.

Front 44

True/false: One user record can only be assigned to one profile.

Back 44

TRUE: One user record can only be assigned to one profile. It is possible to create more than one user with the same email address – however, the username (which is typically the user’s email address) must be unique across all orgs.

Front 45

Why wouldn't you use a standard profile and then add permission sets as needed?

Back 45

You cannot modify most of the standard profiles. Yes, using permission sets for everything would create significant overhead managing all of the permissions on a per user basis.

Front 46

Name the 5 main types of security in Salesforce.

Back 46

* Organization Security
* Object Security
* Record Security
* Field Security
* Folder Security

Front 47

What is Organization Security?

Back 47

Org-level permissions determines under what conditions a user can login to Salesforce, for example:

* When users can login (Login Hours)
* Where users can login from (Login IP Ranges)
* How users can login (API, UI, etc.)

Front 48

What is Object Security?

Back 48

Object-level permissions determines what actions (Create, Read, Edit, Delete) a user can perform on records of each object.

Front 49

What kind of permission does a user need to create a record of any object type?

Back 49

Create permission on the object level (ie Create permission on Accounts in order to create new Account records.)

Front 50

What kind of permission does a user need in order to perform an action on an existing record?

Back 50

The user needs the corresponding object-level permissions and record-level permissions.

Front 51

What is record security?

Back 51

The level of security placed on each record.

Front 52

Why are the 3 tiers of record-level permissions?

Back 52

* Read Only
* Read/Write
* Full Access

Front 53

"Full Access" is granted to:

Back 53

*The record owner

*Users higher in the role hierarchy than the record owner )when "Grant Access Using Hierarchies" is enabled)

*Users with "Modify All" object-level permissions (including system administrators)

*Members of a queue to all records owned by the queue

Front 54

True/False: You can share "Full Access" via sharing rules.

Back 54

False. It is not possible to share “Full Access” via sharing rules or other mechanisms at this time.

Front 55

If a user has edit permissions on a record, but not delete permissions, is there a way they can still delete that record?

Back 55

Yes. Beware that if they have the permission to 'transfer record', then they can transfer it to themselves to become the owner of that record, and then delete it.

Front 56

Name an object that does not have record owners and will not adhere to the record owner rules because of this.

Back 56

Products

Front 57

What 2 settings do field-level permissions have?

Back 57

*Visible

*Read-Only

Front 58

What types of data are secured using folders?

Back 58

*Reports

*Dashboards

*Email templates

*Documents

*Similar to list views as well

Front 59

True/False: Read/write and full access are the same.

Back 59

False. Read/Write allows you to edit the record. Full access allows you to delete it.

Front 60

What are user permissions?

Back 60

User permissions specify what tasks users can perform and what features users can access.

Front 61

Describe Queues.

Back 61

Queues are used for a variety of purposes. Each queue can include multiple users, and is assigned to one or more objects. Members of the queue can then take ownership of a queue's records.

Example: leads generated from the company's website are routed to a lead queue. Members of the sales team then take ownership of leads owned by the queue as they have availability to call additional leads.

Front 62

What are Custom Permissions?

Back 62

Custom permissions can be used to define permissions within a custom application or process. A developer can define a permission to represent the user's ability to perform an action. This custom permission can then be assigned through the use of a profile or permission set.

Front 63

Describe the capabilities of Single Sign-On (SSO.)

Back 63

Single Sign-On provides the capability for a user to login to one system and have access to more additional systems facilitated systematically as a result.

Front 64

What is an example of SSO?

Back 64

A user may authenticate to their network through Active Directory and thereby be granted access to Salesforce.com without providing a username and password.

Front 65

What is the Salesforce App Launcher?

Back 65

The Salesforce App Launcher is a single sign-on portal, allowing users to launch both Salesforce and external applications (external apps via single sign-on.)

Front 66

How can you monitor Salesforce system performance and security?

Back 66

Trust.salesforce.com offers monitoring of system and security status, as well as finding best practices from Salesforce.