Salesforce Security Model

Public Group

A collection of individual users, other groups, individual roles or territories, and/or roles or territories with their subordinates that all have a function in common.

Permission set

A collection of settings and permissions that give users access to various tools and functions. The settings and permissions in permission sets are also found in profiles, but permission sets extend users' functional access without changing their profiles. Permission sets make it easy to grant access to the various apps and custom objects in your org, and to take away access when it's no longer needed. Users can only have one profile, but they can have multiple permission sets.

Settings vs Permissions (in user profile)

A profile's settings determine whether a user can see a particular app, tab, field, or record type. A profile's permissions determine whether a user can create or edit records of a given type, run reports, and customize the app.

Tab visibility options (permission sets / profiles)

Available / Default Off — The tab is available on the All Tabs page. Individual users can customize their display to make the tab visible in any app. Available and Visible / Default On — The tab is available on the All Tabs page and appears in the visible tabs for its associated app. In Lightning Experience, this setting determines whether an object appears in the App Launcher and in navigation menus. Individual users can customize their display to hide the tab or make it visible in other apps. None / Tab Hidden — The tab isn't available on the All Tabs page or visible in any apps.

Why is it easier to use a public group when defining a sharing rule?

Because it's easier to organize a sharing rule for a grouping of individuals, especially if you need to utilize multiple sharing rules.

What is CRUD's equivalent in Salesforce?

CRED: Create, Read, Edit, Delete

CRUD operations

Create, Read, Update, Delete

Types of Tabs (6)

Custom Object Tabs — For your custom object data. Custom Object Tabs display the data of your custom object in a user interface tab. Custom object tabs look and function just like standard tabs. Web Tabs — For other web content Custom Web Tabs display any external Web-based application or Web page in a Salesforce tab. You can design Web tabs to include the sidebar or span across the entire page without the sidebar. Visualforce Tabs — For Visualforce pages Visualforce Tabs display data from a Visualforce page. Visualforce tabs look and function just like standard tabs. Flexible Page Tabs — For Flexible Pages, to include them in the Salesforce1 navigation menu. Flexible Page Tabs let you add Flexible Pages to the Salesforce1 navigation menu. Lightning Component Tabs — Lightning Component tabs allow you to add Lightning components to the navigation menu in Lightning Experience and the mobile app. You can't access the Lightning Component tab outside of the mobile app. For example, you can't access the Lightning Component tab from the full Salesforce site. Lightning Page Tabs — Lightning Page Tabs let you add Lightning Pages to the mobile app navigation menu. Lightning Page tabs don't work like other custom tabs. Once created, they don't show up on the All Tabs page when you click the Plus icon that appears to the right of your current tabs. Lightning Page tabs also don't show up in the Available Tabs list when you customize the tabs for your apps.

Does setting 'Read' for Accounts in a profile allow any user with that profile to see all accounts?

No. By default, it will only allow them to see accounts that they own. To enable the user to see other accounts, record-level security settings must be changed.

Are Tabs a security mechanism?

No; they are a "what you can easily see" mechanism, but you can still be linked something that you do not have a tab for.

Four types of Record-level security

Org-wide defaults: You can specify the default level of access users have to each others' records. Role hierarchies: These give access for users higher in the hierarchy to all records owned by users below them in the hierarchy. (They don't have to match your organization chart exactly.) Additive only. Sharing rules: Automatic exceptions to org-wide defaults for particular groups of users, so they can get to records they don't own or can't normally see. Additive only. Manual sharing: This allows owners of particular records to share them with other users.

Levels of Data Access

Organization, Objects, Fields, Records

Org-wide defaults: object settings (4)

Private: Only the record owner, and users above that role in the hierarchy, can view, edit, and report on those records. Public Read Only: All users can view and report on records, but only the owner, and users above that role in the hierarchy, can edit them. Public Read/Write: All users can view, edit, and report on all records. Controlled by Parent: A user can view, edit, or delete a record if she can perform that same action on the record it belongs to.

What grants Object-level security?

Profiles and permission sets.

Audit System Use

Record Modification Fields: All objects include fields to store the name of the user who created the record and who last modified the record. This provides some basic auditing information. Login History: You can review a list of successful and failed login attempts for the past six months. Field History Tracking: You can turn on auditing to automatically track changes in the values of individual fields. Although field-level auditing is available for all custom objects, only some standard objects allow it. Setup Audit Trail: The Setup Audit Trail logs when modifications are made to your organization's configuration.

Object-level security

Simplest level of security to control. You can set permissions on a particular object type to prevent a group of users from creating, viewing, editing, or deleting any records of that object.

What happens when object-level permissions conflict?

The most restrictive settings take effect.

What permissions can user profiles control?

The profile determines: • The objects and fields a user can access. • What they can do with any object record (such as create, read, edit, or delete).

True / False: A user can see records that they own.

True.

True / False: Grant Access Using Hierarchies can be disabled for an object.

True.

True / False: Org-wide defaults can never grant users more access than they would have through their object permission.

True.

True/ False: You need access to an Object to have access to the Records for that object.

True.

True/False: Org-wide default settings can be set separately for each type of object.

True.

What determines base-level security?

User Profiles.

Data Administration permissions

View All Data Modify All Data

When would you modify field-level security?

When you want users to have access to an object, but limit their access to individual fields in that object.

Record-level security

You can allow particular users to view an object, but restrict the individual object records they're allowed to see. There are four different types of record-level security (on a different flashcard).

Field-level security

You can restrict access to certain fields, even if a user has access to the object.

How do Role Hierarchies work?

• A manager always has access to the same data as his / her employees, regardless of the org-wide default settings. • Users who tend to need access to the same types of records can be grouped together.

You use permission sets for what two general purposes?

• Grant access to custom objects or apps. • Grant permissions to specific fields.

CRED operation prerequisite

• Read <- nothing • Create <- Read • Edit <- Read • Delete <- Edit, Read • View All <- Read • Modify All <- Read, Edit, Delete, View All

Ways to modify field-level security

• Restrict field access with a profile. • Add field access with a permission set.

Each sharing rule has three components:

• Which records to share • Which users to share with • What kind of access (Read-only or Read/Write)

Org-level security

•Maintain a list of authorized users. •Set password policies. •Limit logins to certain hours and locations (IP ranges).

The permissions on a record are evaluated according to...

...a combination of object-level, field-level, and record-level permissions.