Salesforce Security Mastery: Object, Permission Sets, Field, and Record-Level Strategies with OWD

What You’ll Learn

1. How to protect an Object in Salesforce Security?
2. What is Profile Level Security?
3. What is Permission Set in Salesforce?
4. Difference between Profile and Permission Set?
5. What is Field Level Security or FLS?
6. How to achieve a Field level of Security?
7. What is record-level security?
8. Types of Implementing Salesforce Record-Level Security
9. What is Organisation Wide Default?
10. Mechanism of OWD
11. How does OWD work?

Salesforce Object Level Security is a straightforward method for managing data access. It restricts users or groups of users from performing actions such as creating, viewing, editing, or deleting records of a specific object by establishing permissions for that object.

Object permissions can be set in two ways:

1. Profiles: Profiles define the objects that a user can access and the level of access they have to each object’s records.
2. Permission Sets: Permission Sets offer additional permissions and access settings for users. Unlike Profiles, Permission Sets cannot restrict existing permissions granted to users at the Profile level. Permission Sets can only be assigned to users, not to Profiles.

Profiles In Salesforce

In Salesforce, a profile serves as a blueprint, defining the data and features accessible to users within the platform. It’s like a template that can be customized to meet specific requirements.

When creating a new profile, you must select an existing Salesforce profile as a starting point. This eliminates the need to manually configure all permissions and settings from scratch.

Settings control what users can view, such as apps, tabs, fields, and record types. Permissions, on the other hand, determine what users can do, such as creating or editing records of a particular type, running reports, or customizing the application.

1. Profiles Control

• Object Permission
• Field Permission
• User Permission
• Tab Settings
• App Settings
• Apex class access
• Visualforce page access
• Page Layouts
• Record Types
• Login Hours
• Login IP Ranges

Profiles are typically defined by a user’s job function but anything that makes sense in an organization can be created as a profile. The platform includes a set of standard profiles. Each of the standard profiles includes a default set of permissions for all of the standard objects available on the platform.

2. Standard: Standard User profile has Read, Edit, and Delete permissions to most standard objects

3. Read Only: The Read-only users had permissions exactly similar to the standard user but limited access to read-only.

4. Marketing User: Permissions of Standard User + Additional Permissions.

5. Contract Manager: Permissions of Standard User + Additional Permissions.

6. Solution Manager: Permissions of Standard User + Additional Permissions.

The System Administrator profile holds the highest level of access to data and the most extensive capabilities for configuring and customizing Salesforce. It also possesses two unique permissions: “View All Data” and “Modify All Data”. Upon creating a custom object, most profiles, excluding those with “Modify All Data” permission, are not granted access to that object.

Note: Object permissions on the Standard profile are immutable. To circumvent this restriction, it is advisable to create a new profile by copying or cloning the Standard profile and then tailoring the copies to meet the organization’s specific requirements.

The profile functionality within an organization is contingent upon the user license type.

Key Points:

1. Every profile must have at least one visible app.
2. Even if an app is visible, its tab will not appear unless the profile has permission to view the associated objects.
3. A profile can be assigned to multiple users, but a user can only be assigned to one profile at a time.

Permission Sets

Permission sets in Salesforce, also known as object-level security, are collections of settings and permissions that govern users’ access to various tools and functions within the platform. These settings and permissions are similar to those found in profiles, but permission sets offer an additional layer of control without altering existing profiles.

Permission sets are particularly useful for granting specific users additional access beyond their existing profile permissions. This eliminates the need for modifying existing profiles, creating new ones, or assigning unnecessary administrator privileges. By utilizing permission sets, organizations can fine-tune user access with greater precision and flexibility.

Permission Set Control

1. Object Permission
2. Field Permission
3. User Permission
4. Tab Settings
5. App Settings
6. Apex class access
7. Visualforce Page Access
8. There are a couple of ways to use the Permission Set in Salesforce:

• To grant access to custom objects or entire apps.
• To grant permissions-temporarily or long-term time-specific fields

Permissions are additive which means we can’t remove a user’s existing permissions by assigning a permission set we can only add permissions To limit access for a user or group of users, ensure that their base profile as well as any of their permission set limits this type of access. It is not mandatory to give the license to the permission sets while creating it, but once the license is assigned it cannot be changed.

Permission Sets Expiration In Salesforce

Set assignment expiration dates and assign permissions that expire to users via permission sets. You can specify the expiration date with 1 day, 7 days, 30 days, 60 days, and a custom date from the permission set assignment. Difference Between Profile And Permission Sets

Field-level security

Field-level security in Salesforce grants granular control over user access to specific fields within an object’s record. Unlike page layouts, which merely regulate field visibility on detail and edit pages, field-level security extends this control to all areas of the application, including related lists, list views, reports, and search results.

Enforcing field-level security restricts users from accessing the field anywhere within the organization, including within formula fields. However, hiding a field from the page layout does not prevent users from utilizing the field’s value; it merely conceals the field within the page layout.

Field-level security can be applied to multiple fields on a single profile or permission set, enabling precise control over user access. Additionally, field-level security can be applied to a single field across all profiles, ensuring consistent access restrictions for all users.

Methods for Implementing Field-Level Security in Salesforce:

1. Utilizing Profiles to Limit Field Access:

Profiles serve as a means of controlling users’ overall access to fields by granting them Read Access or Edit Access to specific fields. This approach allows for granular control over user permissions while maintaining a consistent access structure for all users belonging to the same profile.

2. Employing Permission Sets to Expand Field Access:

Permission sets provide a flexible mechanism to extend user access to fields that are restricted in their assigned profiles. By granting permission sets, administrators can tailor user permissions to specific needs and roles, ensuring that users have access to the fields they require while maintaining data security.

Note: Field-level security can also be configured directly from the field accessibility settings in Salesforce Setup. This method offers a more direct approach to managing field permissions for individual fields

Record Level Security

Record-level security in Salesforce empowers administrators to refine user access permissions, granting granular control over individual records within each object. This mechanism extends beyond the broader access controls governed by object-level permissions, enabling administrators to determine which users can view, edit, or even see specific records.

When evaluating access to a record, Salesforce considers a combination of object-level permissions, field-level permissions, and record-level security permissions. If conflicting permissions exist, the most restrictive settings take precedence, ensuring data security prevails.

To effectively implement record-level security, administrators need to address two key questions:

1. Access Scope: Should users have unrestricted access to all records within an object, or should access be limited to a specific subset?
2. Access Rules: If access is restricted, what rules should determine which users can access specific records? This may involve defining criteria based on user roles, relationships with record owners, or other relevant factors.

Salesforce provides four primary methods to implement record-level security, each offering unique capabilities to tailor user access:

1. Organization-Wide Defaults (OWD): OWD sets the default level of access users have to each other’s records within an object. This serves as the baseline access level, which can be further refined using other record-level security methods.
2. Role Hierarchies: Role hierarchies leverage a hierarchical structure, ensuring that managers have access to records owned by their subordinates. This approach is particularly useful for organizations with well-defined reporting relationships.
3. Sharing Rules: Sharing rules provide more granular control over record access by creating automatic exceptions to OWD for specific groups of users. These rules can be based on various criteria, such as user roles, record owner relationships, or custom fields.
4. Manual Sharing: Manual sharing grants record owners the flexibility to directly share read or edit permissions with individual users, even if those users do not have access to the record based on OWD or other sharing methods. This approach is particularly useful for granting access to specific users who may need to collaborate on certain records.

By carefully considering the access scope and defining appropriate access rules, administrators can leverage these record-level security methods to ensure that users have the access they need while maintaining data security and privacy.

Organization-Wide Defaults (OWD)

Organization-Wide Defaults (OWD), also known as Organization-Wide Sharing Settings, serve as a foundational mechanism for regulating user access to records within Salesforce. These settings establish the baseline level of access for all records belonging to a specific object. It’s important to note that OWD cannot grant users more access than their object permissions allow.

Balancing Security and Accessibility: Choosing the Right Access Level

OWD offers three distinct access levels, each tailoring the level of access users have to records:

1. Public Read/Write: This setting grants all users the most comprehensive access, allowing them to view, edit, and report on all records within the object.
2. Public Read-Only: Under this setting, all users can view and generate reports on records, but they cannot edit them. Only the record owner and users above them in the hierarchy retain editing privileges.
3. Private: This setting imposes the most restrictive access, limiting the ability to view, edit, and report on records to the record owner and users above them in the hierarchy.

OWD as the Cornerstone of Record-Level Security

OWD should be considered the cornerstone of record-level security in Salesforce. This is because other record-level security implementations, such as role hierarchies and sharing rules, can only grant additional access; they cannot restrict the access granted by OWD. Therefore, carefully selecting the appropriate OWD setting is crucial for maintaining data security while ensuring users have the necessary access to perform their tasks.

Mechanism of OWD

To determine the Organization-wide default of an object consider the below diagram:

The data may be too restrictive for some users according to org-wide defaults but it can be opened for users who need more access using role hierarchies, sharing rules, and manual sharing. A sharing recalculation starts applying access changes to records whenever an update is made for Organization-Wide Default settings. An email is sent by Salesforce whenever it gets completed or we can see the update on Setup Audit Trail.

Note

Regardless of the record-level security settings applied to a user, the record owner always retains full access to the record, including all permissions granted by the object-level permissions. This ensures that record owners maintain control over their data and can perform all necessary actions, even if their record-level security settings would otherwise restrict their access.

Conclusion

Object Level Security, Permission Sets, Field Level Security, Record Level Security, and OWD are all essential tools for protecting Salesforce data. By using these features effectively, you can prevent unauthorized access, data breaches, and compliance violations.
I hope you enjoyed this informative blog post. If you have any questions or require further assistance, please feel free to leave a comment below. Don’t miss out on future articles by following me on LinkedIn, Instagram, and Twitter. Stay tuned for more exciting content!

Originally published at https://amansfdc.com on November 14, 2023.