Warning: Undefined array key "src" in /home/customer/www/sfdcnotes.com/public_html/wp-content/plugins/advanced-responsive-video-embedder/php/functions-shortcode-args.php on line 398

This chapter’s objectives are:

• 4.1- Explain the various organization security options (e.g., passwords, IP restrictions, identity confirmation, network settings)
• 4.2- Describe the features and capabilities of the Salesforce sharing model (e.g., record ownership, organization-wide defaults, roles and the role hierarchy, manual sharing, sharing rules and public groups)
• 4.3- Given a scenario, apply the appropriate security controls (e.g., organization-wide defaults, roles and the role hierarchy, manual sharing, sharing rules and public groups)
• 4.4- Describe the various settings and permissions a profile controls (e.g., IP access, login hours, record types, access to tabs, permissions, object permissions, field-level security)
• 4.5- Given a scenario, determine the appropriate use of a custom profile

---

4.1- Explain the various organization security options (e.g., passwords, IP restrictions, identity confirmation, network settings)

Check series: Who Sees What: Data Visibility How to Series

ARVE Error: Need Provider and ID to build iframe src.

Video 1 – Organization Access through Login IP, Login Hours and Trusted IP Ranges

1- Create and activate users and allow them to login using: Login IP (where), Login Hours (when) and Trusted IP Ranges

• Login IP and Login Hours will DENY access if you don’t meet their settings
• Login IP, Login Hours setup under Administer } Users | Profiles – Click on Profile and scroll down to bottom
• Trusted IP Range under Administer } Security Control | Network Access – New trusted IP Range

Video 2 – Object Access through PROFILES

2- Once logged in, users should have access to APPS and OBJECTS = PROFILE. Profile determines which Apps, Tabs and Objects he can access, how information is displayed to the user (page layouts, record types, field-level security) and what Permission he has on each Object Records (Create, Read, Edit, Delete View All and Modify All, and many other permissions.

• There exists default Profiles that you can clone
• Notable Profiles: see right picture. Note that System Admin has 2 super powers: “View all” data and “Modify all data” – these permissions override all Sharing Rules in settings!).
• As customization of standard profiles is limited, create custom profiles prior to assigning users to profiles.
• Enable “Enhanced Profile User Interface” will give a better Profile page layout that is divided into 2 sections:
  • Access it: Build | Customize | User Interface | and checkbox “Enable Enhanced Profile User Interface”
• App Settings: which Apps available, Object, Tabs that have access to and their specific permissions.
  • For example: “Assigned Apps” checkbox which Apps this profile can see,
• Object Settings gives permission to each Object: Read, Create, Edit, Delete, View all, Modify all. Example, you can prevent Opp deletion here. “Object Settings” also makes the tab Hidden, default Off or default On (this is only for the Tab view, unrelated to what you can see as records in reports and lists).
• System Settings: Login IP and Login Hours, Password policy, System Permission (for any App)…
• Access Profile through:
  • Adminster | Users | Profile | you can clone and use a profile as a basis of a new profile – Can assign users from Profile, or from User page itself.

  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Video 3: Org-Wide Defaults (OWD)

3- Now that you have granted the user his Profile, you should define what the user Permission is to the records that you do NOT own? This is configured by OWD for each Object. OWD 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.

• Profile Permission is the Baseline Permission – starting point – the MAX permission you could have!
• OWD cannot grant permissions more than the Profile Baseline permissions
• Example, if Profile Baseline permission is CR (Create Read), and the OWD is Public Read Write, you cannot edit ANY record as you don’t have Edit in the Profile Baseline, even though you have Write in the OWD.
• This is mainly how do I deal with records that I do not own – regardless of Tree. ANY Record that I do not own!
• Until now, in Video 2, we gave the Permissions below on the right. These are for the Records that you OWN. What about the access and permissions of Records you don’t own?! This is Org Wide Defaults.
• You set default access level for each Object (other of what you own)
• Settings for each Object: Private (can’t even see), Public read, Public Read Write, Public read Write Transfer.
• Access OWD and Object Sharing Rules through:
  • Administer | Security Control | Sharing Settings

Video 4: Roles and Role Hierarchy

4- Until now, we have Profile Baseline permission (Records that you own and your max Permission) and OWD (anything that you do not own). What if you want to make your manager access your records?

• Role hierarchy is a way to extend access to Records when the OWD is set to anything more restrictive than “Public Read Write”. Because if OWD is “Public Read Write”, Role is redundant
• Which RECORDS users have access to = ROLE. For example, SM should have visibility to all Opps of his team.
• The Role hierarchy CANNOT grant you more permission as your Baseline profile permission.
• It can only open up access, cannot restrict access to less than what is granted in the OWD
• Note that for the Roles Hierarchy to work:
  • The record is owned by a user in a subordinate role.
  • The object has “Grant Access Using Hierarchies” enabled in the OWD.
• Access Role through:
  • Administer | Users | Role
  • You will see the Role tree, you can add roles and assign users here

 

 

 

 

 

 

 

 

 

 

 

 

Video 5: sharing rules

5- Now you can share vertically through Role and Hierarchy, but what if you want to share your Records with another Role or Group that is in a different tree branch in the Role Hierarchy? Use sharing rules.

• Can be used when OWD is set to anything more restrictive than Public Read Write, otherwise redundant
• For example, if the OWD for Opportunity Object is Private and Role Hierarchy is applied, this means that only owner can see his Opportunities and also his manager through Role hierarchy.
• What if you want to share your Opportunities with another Role or Group that is in a different tree branch?
• Role grants access is Vertical Sharing Rule can be Vertical or Horizontal
• Sharing Rule can be based on Record Owner or Record Criteria that you choose
  • Access Profile through: Administer | Security Control | Sharing Settings
• Sharing can be among any to any of: Roles, Roles and Subordinates, Public Group, Manager Group, Manager Subordinates Group
• Or it can be by Record criteria to be shared with one of the above
• You can specify the sharing access level: Read Only, or Read/Write

Manual Sharing

6- What if you want to share your Record with another 1 user, without the need of creating a Sharing Rule? You use Manual Sharing.

• Manual sharing is through a button on the Record page
• The button should be added to the Page Layout
• The button will appear if the OWD is more restrictive than “Public Read Write” because if it were “Public Read Write”, there is no need to share as it is already shared with all users Read and Write
• To share, go to the Record that you want to share and click on Sharing

How the layers works so far: Baseline Profile Permissions, OWD, Role, Sharing Rules, Manual Sharing

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Video 6: Field level security (FLS)

Your Salesforce org contains a lot of data, but you probably don’t want every field accessible to everyone. For example, your payroll manager probably wants to keep salary fields accessible only to select employees. Individual Fields should only be seen to certain profiles – FIELD LEVEL SECURITY

• It allows to Grant or Restrict field visibility based on user profile
• Available in Enterprise, Unlimited, Performance, and Developer Editions only.
• Restrict users’ access to view and edit fields on detail and edit pages.

Custom Field example: Max budget:

• Edit to go to field settings
• If make it Required, then you cannot make it invisible

1- Field Level Security (FLS):

• FLS overrides both the Modify All Data and View all Data user permissions (part of the System Admin profile)
• To set field FLS, go to the Object (custom or standard), then Field – click on the “Set Field Level Security” button on the top of the Field properties

  

• The FLS on the right, is the exact same FLS you access when you go to the Profile in question
• Can also access FLS from Profile itself

2- Page Layout Visibility:

• Configured on the Page layout for each field
• Field can be Read-Only or Required

1 and 2 – Field Accessibility:

• Field Accessibilty is the summary of what field access each Profile has on the field in question (FLS + Layout)
• 2 ways to access Field Accessibility:
  • 1- In the field page You can click on “Field Accessibility” to get the full page containing both FLS and Layout options
  • 2- You can also go to ALL Field Accessibility of All Objects by: Administer | Security Controls | Field Accessibility. Advantage of this: can be by Field or by Profile

 

• Note: FLS override any less-restrictive field access settings in layouts: For example, if a field is required in the page layout and read only in the field-level security settings, the field-level security overrides the page layout and the field will be read only for the user.

 

 

 

 

 

 

 

Video 7: User Sharing

Share a single user record with individual users, personal or public groups, the users in a particular role, or the users in a particular role plus all of the users in roles below that role

• For instance when 1 or more of your users need access to all other user records – for example HR and Finance need access to all user records
• Overrides OWD and sharing for user object only
• To share a single user with another group, go to the User record | click on the Sharing button | add the user or group that this user is shared with
• Individual sharing can only be used to grant wider access to data, not to restrict access.
• If you want to grant a profile to see all users, you can do it in the Profile permissions, or Permission Set for 1 user

Video 8: Permission Sets

What if 1 user needs access to additional permissions and settings than what his profile has? Use Permission Sets Permission set is just like a Profile, but it is applied to 1 user only. This way you don’t need to create too many profiles, just Permission Sets for the special users. This will grant access to these users only.

• 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.
• Extends the user’s access and permissions
• Contains many of the settings found in Profiles
• Access it via:
  • Administer | Manage Users | Permission Sets
  • Create and name a PS.
  • PS has 2 sections: Apps and System Settings (same as the Profile permission page)
  • Add the rules you want, for example, Delete Leads (Object Permission) and Transfer Leads (App permission)
  • Finally Assign it to the user: click on Manage Assignment, and add the user you want this PS applied on
  • you can also add Permission Set to a user by going on the User page and scrolling down to permission set section and ADD

Video 9: Record Types

Check the Record Types chapter in “5- Standards and Custom Objects”

Notes:

• 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.
• 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.

---

4.2- Describe the features and capabilities of the Salesforce sharing model (e.g., record ownership, organization-wide defaults, roles and the role hierarchy, manual sharing, sharing rules and public groups)

Sharing is to grant Record Access (Record level security)

Sharing Models:

• Sharing rules: What if you want to share your Records with another Role or Group that is in a different tree branch in the Role Hierarchy? Use Sharing Rules.
• Manual Sharing: What if you want to share your Record with another 1 user, without the need of creating a Sharing Rule? You use Manual Sharing.
• User sharing: Share a single user record with individual users, personal or public groups, the users in a particular role, or the users in a particular role plus all of the users in roles below that role
• Note: How to share record visibility based on field value? Set the Organization Wide Defaults to Private and then use Criteria based Sharing Rules to open up access to records based on field values
• How to share a single user records with another? Use Sharing Rule with Groups presenting the user(s)

Groups:

• Public groups are used to streamline the process of sharing access to records and folders.
• A group is comprised of users, roles, and other groups.
• Group Types:
  • Public Groups: created by admins, can be referenced in org-wide configuration (such as sharing rules. Note that Sharing Rules cannot share individual user records with another individual user. For that you should create Groups that represent 1 or 2 users to use Sharing Rules with).
  • Personal Groups are created by users, and can only be referenced in select configuration (such as Outlook contact synchronization).
• Use Cases:
  • Sharing access to records or folders with named users (this requires a public group) – For example haring Rules applies to Roles and Groups, not users!
  • Sharing access to multiple Roles at the same time
• 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).
• When groups are referenced in sharing rules, “Grant Access Using Hierarchies” can be extended to group access.

 

Manager Groups:

Manager Groups allow you to Share a Record with your manager and his managers chain. Manager Subordinates Groups will allow you to share the record with all uses in tree hierarchy under your Manager (might be more than one role).

• Manager Groups is disabled by default, but can be easily enabled by Admin
• As admin, you can enable Manager Groups from Setup | Security Controls | Sharing Settings, look for Organization-Wide Defaults and click Edit button, scroll down to Other Settings and select Manager Groups and then click Save.

  

• When Manager Groups sharing setting is enabled, user can manually share a record to Manager Group and Manager Subordinates Group by click “Sharing” button from any page layout, additional option Manager Groups and Manager Subordinates Groups will be available on top of current option.

---

4.3- Given a scenario, apply the appropriate security controls (e.g., organization-wide defaults, roles and the role hierarchy, manual sharing, sharing rules and public groups)

• Who is the most restricted user of this object? Standard employee.
• Is there ever going to be an instance of this object that this user shouldn’t be allowed to see?
  • Yes – Sharing model is Private
• Is there ever going to be an instance of this object that this user shouldn’t be allowed to edit?
  • Yes – Sharing model is Public Read Only
  • No – Sharing model is Public Read/Write

---

4.4- Describe the various settings and permissions a profile controls (e.g., IP access, login hours, record types, access to tabs, permissions, object permissions, field-level security)

Profiles controls:

• Which standard and custom Apps users can view? Which is the default App?
• Permissions per Object that allow users to create, read, edit, and delete records
• Which Object tabs users can view?
• Which page layouts users see?
• Which record types are available to users? (for example, in Cases, Internal and External)
• Which fields within objects users can view and edit

  

• Permissions per App:

  

• Custom Permission for the Profile:

  

• Admin Permissions that allow users to manage the system and apps within it
• Which Apex classes and Visualforce pages users can access
• Which desktop clients users can access
• The hours during which and IP addresses from which users can log in (Login hours, Login IP)
• Which service provider’s users can access (if Salesforce is enabled as an identity provider)

---

4.5- Given a scenario, determine the appropriate use of a custom profile

• A profile is a collection of permissions and other settings associated with a user or a group of users. Your organization has a number of standard profiles already defined. If you create a custom object, the permissions to access that object (“Read,” “Create,” “Edit,” and “Delete”) are disabled for most profiles. This security setting ensures that access to custom objects and their data is only explicitly granted to users. You can change these permissions in custom profiles, but not standard profiles. You should clone the standard Profiles and edit the clone.

---

4.6- Extra Notes

Delegated Administration:

• Delegated administration allows named users to manage other users within selected roles and profiles, as well as manage fields on selected custom objects. Why? If you give full Admin privileges to any user = Danger!
• Delegated admin allows you to specify which users (based on role/profile) and custom objects (standard objects excluded) a delegated administrator can manage.
• Use delegated admin to assign limited administrative privileges to users who aren’t administrators. For example, make the Customer Support team manager a delegated administrator to manage users in the Support Manager role and all subordinate roles.
• Create it: go to Administer | Security Controls | Delegated Administration
• Give a name for the “Delegated Group Name”
• You can check the box “Enable Group for Login Access” to allow the group’s delegated Admin to Login As
• We just created a delegated group! Now add details, such as which users are delegated administrators for the group. Click the info bubbles in the related lists to learn about the attributes you can add:
  • Delegated Admins (DA): assigned delegated
    Admins
  • User Administration: DA can create and edit and reset pass for these roles and subordinates
  • Assignable Profiles, Permission Sets (PS) and Public Groups: DA can assign these profiles, PS and Groups to the users he can administer
  • Custom Obj. Permission: which objects and tabs admin can administer

Custom Permissions

• Custom permissions can be used to define permissions within a custom application or process.
• For example, your organization has implemented a custom application in Salesforce to track leave requests. One of the buttons in the application invokes a custom process (apex/VisualForce code) to mass approve leave requests.
• Previously, if a developer wanted to define a permission to mass approve leave requests, this was often configured through the use of a custom field on the user object (e.g. checkbox “Can Mass Approve Leave Requests”) or via the use of a hierarchy-based custom setting. Both of these approaches have limitations.
• With custom permissions, a developer can define a permission to represent the user’s ability to mass approve leave requests. This custom permission can then be assigned through the use of a profile or permission set, like any standard Salesforce permission.
• Creating and defining custom permissions would be performed by a developer. However, administrators should be aware of custom permissions and the potential security implications when used.

Single Sign-On:

• Single Sign-On provides the capability for a user to login to one system and have access to one more additional systems facilitated systematically as a result. For example, a user may authenticate to their network through Active Directory (Microsoft Windows) and thereby be granted access to Salesforce.com without providing a username and password.

Setting up the App Launcher

• The Salesforce App Launcher is a single sign-on portal, allowing users to launch both Salesforce and external applications Connected Apps (external apps via single sign-on).
• When I click on the Apps (external), I get SSO logged in
• Profile or Permission Set for the user:
  • Add the allowed Apps in the “Assigned Connected Apps” permission
  • “Use Identity Features” (Gives the user access to Identity features such as App Launcher.
  • Enable the App Launcher App (make it Visible for this Profile)
• Order of Apps in Setup | Manage Apps | App Menu
• Manage Connected Apps in Setup | Manage Apps | Connected App (you should install Apps first and do:
  • Connected App needs a Start Url: copy the IdP initiated URL and make it the start URL
  • Add Profile to the App: Manage Profile – select the Profile – Save
• Check: https://www.youtube.com/embed/WDElVK9SXjA

Monitor Salesforce instances:

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