Accessing Features and Objects in Salesforce

In the Salesforce world, features and objects form the backbone of its functionality.  Understanding and accessing these features and objects are fundamental steps in tailoring Salesforce to meet the  needs of your organization to improve  efficiency and implement customization. There are numerous settings that can be used by the SF Admin to control how objects, records, and fields are accessed.

‍

Access Settings

‍

Setting Access to Objects: Object access is granted through CRED Permissions that are assigned through a Profile, Permission Set, or Permission Set Group. CRED is an acronym for Create, Read, Edit, Delete. These are permissions that can be assigned at the Object level.

Object Permissions: These permissions define the kinds of objects users can perform CRED operations on, but they do not define CRED actions on the individual records in the object. Permissions such as "View All" and/or "Modify All" determine if the users can not only view the records, but CRED action on the records as well. Note, “View All” and “Modify All” permissions ignore sharing rules and settings.

Profiles: A profile is responsible for defining how the user accesses objects and data. and the actions they can take within the application. You can only assign a single profile to a user. Profiles define the settings determining what a user can see, i.e. Assigned Apps, Tabs, Record Type Assignments, Page Layout Assignments, and Field Permissions. Permissions define what a user can do, i.e. App Permissions, System Permissions, and CRED settings for Custom and Standard Objects.

• Profiles determine which objects a user can access and the level of access they have (read-only, read/write, etc.).
• Profiles also control access to specific fields within objects, allowing administrators to restrict sensitive information.
• Permission sets provide a way to grant additional permissions to specific users without changing their profiles. This is beneficial when certain users need exceptions to the standard profile settings.
• Profiles define the fundamental operations a user can perform on an object—viewing, creating, editing, and deleting records.
• Profiles and permission sets can be configured to control access to records based on criteria. This ensures that users only see and modify the records relevant to their role.

Minimum Access Profile: Although Salesforce Provides six (6) standard profiles, best practice is to create custom profiles, by cloning the the Standard Minimum Access profile. The Minimum access profile is the least privileged standard profile. You can assign the appropriate custom profile to a user and add more permissions through permissions sets and permission set groups.

Restrictions Through the Profile:  Admins can restrict Login Hours and Login IP Ranges through the profile. If restrictions are set on the login times and login IP ranges, the user must satisfy both criteria or they will not be allowed to access Salesforce.

Permission Sets: Permission Sets ae the tool to enhance or add additional permissions to an existing profile.

• Permission sets are used to grant additional permissions to users without changing their profiles. This is beneficial when specific users need exceptions to the standard profile settings.
• Permission sets can be assigned to the user from the permission set or from the user record. The user's total access is a function the access granted in their profile plus the access granted by the permission set(s) assigned to them.
• Permission sets can grant access to specific objects and fields, allowing users to interact with certain data even if their profile would normally restrict such access.
• Permission sets can be used to grant access to Apex classes and Visualforce pages, allowing users to execute custom code based on their needs.
• Custom permissions within permission sets enable administrators to create and assign custom rules, further refining user access based on specific conditions.
• Permission sets support dynamic assignments, meaning they can be enabled or muted from users without the need to change their profiles.

‍Permission Set Groups:  Permission set groups are a method of grouping Permission Sets together into a single group.

Muting Permissions:  Admins can disable certain permissions within a permission set or permission set group via muting. Muting will disable the permission until the Admin needs to enable it again in the future.

Fields Level Security (FLS):  FLS affects the visibility and editability of fields on page layouts. Users will only see and be able to modify the fields for which they have the necessary permissions. FLS settings override object-level settings. Even if a user has access to an object, they may be restricted from viewing or editing certain fields if FLS is configured to limit access.

• Field Level Security (FLS) provides granular control over who can view and edit individual fields within an object.
• Configured within user profiles, FLS settings determine which fields users with a specific profile can access.
• Administrators can set separate permissions for reading and editing each field. This ensures users have appropriate access based on their role.
• FLS affects the visibility and editability of fields on page layouts. Users only see and can modify fields for which they have the necessary permissions.
• FLS settings override object-level settings. Even if a user has access to an object, they may be restricted from viewing or editing certain fields.
• Essential for maintaining data security and privacy compliance by ensuring that sensitive information is only accessible to authorized users.
• FLS settings are respected in dynamic Apex code and Visualforce pages, preventing unauthorized access to fields even in custom development scenarios.

Administrators: Admins can access all objects and records by default. There are three types of admins: System Admin, Delegated Admin, and Custom Admin.

Record Owners: User that have Full Access over the records they own and are usually assigned the following rights (VESTD):

• View
• Edit
• Share
• Transfer
• Delete
• Including View All and Modify all on an Object.

Queues: Are containers that hold records, such as leads, cases, or custom objects, allowing for work allocation.

• Can act as an owner of records.
• Members can be composed of public groups, roles, roles and subordinates, and users.
• List view created automatically when queue is created.
• Can be used with leads, cases, tasks, and custom objects.

Record Access:  Determines what records users can view and edit for objects that are accessible via their profiles.

• Org Wide Defaults (OWD) - Private, Public Read/Write/Transfer
• Role Hierarchy
• Sharing Rules
• Teams
• Manual Sharing
• Restriction Rules

Organization Wide Defaults (OWD): Default level of access that determines what a user can do with records they do not own. OWD sharing Settings include Private or Public with combinations of the following access Read, Write, Or Transfer(applies to Leads and Cases).

Role Hierarchy: Allows Admins to grant access vertically to anyone denied access trough OWD.

• Allows users in higher roles to inherit the rights of those below them in the hierarchy.
• Describes visibility to records and should not be confused with an Org chart.
• Custom object records do not have to be inherited. ‍‍

Associated Record Access: Allows Admins to define the level of access an account owner will have to related records that are owned by other users that are not their subordinates.

Implicit Account Access: In short, if a user owns a child record of an Opportunity, Case, or Contact or an Account, the user implicitly has Read access on the Account, assuming they have the correct Object permissions. The Read access cannot be removed.

Sharing Rules: Admins can implement sharing rules to grant record access to groups of users. Sharing rules are designed to grant access in one direction only, and can be assigned to Public groups, Roles, Roles and subordinates, and Queues (for Cases only).

Public Groups: Admins can create a grouping of users for facilitating sharing for many users.

Manager Groups: Allows users to share records with their managers and manager subordinate groups. For example, records owned by Group A users can be shared with the Manager and subordinates of Group B.

Opportunity Teams: Allows users to collaborate on opportunities. Must define roles for team members and set record level access. This gives the member access to only one opportunity.

Account teams: Can be used grant the appropriate Read/Write access to an Account and related contacts, opportunities, and cases. Account roles must be defined for each member.

Case Teams: Allow users to grant access to their cases and related records to users, contacts, or add predefined cased teams. Admins can define member roles, created predefined case teams, configure assignment rules to automatically add cases teams to cases. Up to three different teams can be used on a single case.

Manual Sharing: Allows users to grant ad hoc access to their individual records for users, roles, roles and subordinates and public groups. Manual sharing can be used by record owners, their managers in the role hierarchy, and Administrators. Manual shares are deleted once ownership is changed to another owner or the owner of the record is deactivated.

Restriction Rules: Admins can apply restriction rules through the Object Manager. Restrictions can be applied on Custom Object, contract, Tasks, and Events. Restrictions apply filters and hid records from view.

‍

‍

Security Layers Recap - Access Management

Organization

• Authentication
• Trusted IP Ranges
• Login IP Ranges
• Login Hours

Object:

• License
• CRED Permissions through the Profile, Permissions Set, or Permission Set Group

Record:

• Org Wide Defaults(OWD)
• Role Hierarchy
• Sharing Rules
• Teams and Manual Sharing
• Restriction Rules

Field: 

• Field Level Security (FLS)

‍

‍

‍

‍