Evolving Your Salesforce Security Model: Part 1

Business requirements and overview of the process

You’re likely familiar with the challenges of managing Salesforce user permissions. If you’ve been working with Salesforce for a while, you’ve experienced the headache of dealing with a proliferation of Profiles, each slightly different from the next. Or you’ve struggled with the time-consuming task of troubleshooting security settings or access permissions.

In Part 1 of this two-part series, we’ll show how using an organization Capability Model with Jobs-to-be-Done (JTBD) gives us a roadmap for migrating from the current, Profile-heavy security model to one based on Permission Set Groups. The resulting security model – along with the documentation that you’ll create in the process! – will

• reduce accidental over-permissioning and unauthorized access
• simplify troubleshooting of access problems
• add traceability and auditability of access permissions.

In Part 2, we’ll show a case study of a migration, highlighting recently-introduced security tools that will allow you to begin this transition with confidence.

The Business Requirement for an Improved Security Model

The primary driver for this change is enhanced security. Security vulnerabilities and data breaches are becoming more common and costly. Regulations like GDPR and CCPA emphasize security policies and data governance. Organizations need to ensure that users have access to only the data they need to do their job. Consider this: a recent Change Intelligence Research Report revealed that on average, there are 60 permission controllers with an 80% overlap for access to objects like Account and Contact. This level of redundancy makes it extremely difficult to manage layers of security and security controls effectively, complicating audits and risking security vulnerabilities.

While improved security is the main benefit, the new model delivers significant operational advantages:

• Improved Access Control: By organizing permissions into JTBD-based Permission Set Groups composed of task-based Permission Sets, you can ensure users have exactly the access they need – no more, no less.
• Reduced Administrative Overhead: Once set up, this model significantly reduces the time spent on user management tasks, because it’s clear how permissions are associated with Jobs-to-be-Done and tasks. 
• Better Auditability: With a clear structure based on Jobs-to-be-Done and tasks, it’s straightforward to document and justify why a user has each specific permission.

Challenges with the Current Security Model

Originally, a Profile was the only mechanism to grant permissions to a Salesforce user. Profiles were often associated with user roles in the organization. But if some users in a role needed slightly different – typically, additional – permissions, then the choices were

• create a new Profile, resulting in an explosion of highly-overlapping Profiles, or
• update the existing Profile, resulting in over-permissioning some users.

A lack of tools made it difficult and time-consuming to identify what a Profile could access and to understand the differences between Profiles.

The introduction of Permission Sets allowed an additional, fine-grained way of granting permissions. This was good for defining access required for a specific task but did not address the fact that only Profiles provided an easy way to group permissions for a role. Permission Sets were often used for access to new features. But lack of tools and time made it difficult to prioritize cleaning up Profiles. Therefore, the twin issues of overlapping permission controllers and over-permissioning users only got worse.

As a result, it’s been very difficult to understand precisely which permissions a user has. And even harder to explain why they have those permissions.

Permission Set Groups are a more recent addition. By grouping Permission Sets, a Permission Set Group provides a mechanism to provide a broader scope of permissions (like a Profile), but with the flexibility that comes with being able to assign many Permission Set Groups to a user.

If only there were an obvious way to know how granular to make Permission Set Groups and what new or updated Permission Sets they should contain…

It Starts With a Capability Model of the Organization

A Capability Model is a comprehensive framework that outlines an organization’s core functions, competencies, and activities. It provides a high-level view of what an organization does and how it operates:

1. The Capability Model divides the organization into key functional areas (e.g., HR, Marketing, Finance). These functions represent the broad categories of work the organization performs.
2. Within each function, the model lists the Jobs-to-be-Done (JTBD), the specific outcomes or objectives that the organization aims to achieve within each function.
3. While not directly shown on the Capability Model, each JTBD is linked to process maps and documentation – including security documentation – that define it.

This approach helps stakeholders understand not just what the organization does (capabilities) but also why and how it does these things (Jobs-to-be-Done).

Here’s a portion of the Elements.cloud Capability Model. We use the Elements.cloud diagramming tools to create the model and show the system resources required for the job.

If only there were an obvious way to align Salesforce permissions with the actual work being done in the organization…

A Permission Set Group Represents a Job-to-be-Done

Permission Set Groups allow us to reimagine the Salesforce security model:

The target security model you are aiming for is:

	Current State	Target State
Profiles	Many, Overlapping Permissions	Few
Permission Sets	Many, Inconsistently-defined	Many, Task-based
Permission Set Groups	Minimal / None	Many, JTBD-based

Permission Set Groups become the primary permissions grouping mechanism, ideally organized around the Capability Model’s Jobs-to-be-Done. A Permission Set Group’s job is to grant the permissions necessary for a JTBD.

Permission Sets become a task-based grouping of permissions. The Permission Set’s job is to grant all the permissions necessary to perform a JTBD task, including access to all the associated Flows, Apex Classes, Objects, Fields, etc.

The only remaining job of a Profile is to define the allowed login hours,  login IP address ranges, and default apps and record types.

Tools to Support Your Migration

Before we dive into our recommended process, let’s explore the tools available to make this transition easier.

Salesforce Native Tools

1. User Access Policies: These allow you to automate access assignment based on user attributes or entitlements. You can assign Permission Sets, Permission Set Groups, licenses, public groups, and queues automatically.
2. User Access Summary: Provides a view of which User Permissions a user has and what access they have to objects and fields. Winter ‘25 is adding a row-level “Access Granted By” view that will show the Profiles and Permission Sets that are granting that access. 
3. Object Access (Winter ‘25): Provides a view of all the Profiles, Permission Sets, and Permission Set Groups that are granting access to an Object along with the access level.

Elements.cloud Dependencies and Permissions Explorer

Elements.cloud provides additional tools that complement Salesforce’s native capabilities:

1. Metadata dependencies: Elements can create a graphic display or export a csv of metadata dependencies. For example, if a Field or Object was used in a Flow or Apex Class, there would be one line relating the parent to the child. These dependencies are available for most common metadata types (data: CustomObject, CustomField; automation: Flow, ApexClass, ApexTrigger; reporting: Report, Dashboard).
2. Ask Org Copilot: Provides answers to questions about metadata, dependencies, and permissions, and permission assignments.
3. Permissions Comparison: A granular, pairwise comparison of up to 100 Profiles and/or Permission Sets. For each permission category (Application visibility, Flow access, ApexClass access, Field permissions, etc.) it tells you the % overlap between two permissions. A further drill-down tells you the exact differences between them.
4. Access Analyzer: for anything that can be granted access via a permission controller (Object, Field, ApexClass, Flow, Layout, etc.), provides a report of all users that have access to that metadata item, the Profiles and Permission Sets granting that access, and the specific level of access being granted. ElementsGPT supports an export of all permission assignment details.
5. Compliance Reporting: The “Users with Dangerous Permissions” and “Users with Access to Sensitive Data” reports can help with the initial assessment of over-permissioning. They’re also useful for periodic Salesforce security audits, especially in highly regulated industries. 

In Part 2, we’ll show details of where each of these tools fits in the analysis of existing permissions and deployment of the new permissions.

Migrating to Permission Set Groups

Now that we’re familiar with the available tools, let’s walk through the migration process. Remember, this doesn’t have to be a big bang approach; you can transition gradually.

Example: “Pay Commissions”

From the Elements.cloud Capability Model, we see that one of the Finance Jobs-to-be-Done is “Pay Commissions”. Let’s briefly walk through the process for creating a Pay_Commissions_PSG Permission Set Group. In Part 2, we’ll dive into each step in more detail.

1. Identify the Task: We meet with the VP, Finance and the Finance Analyst responsible for paying commissions. The result is a sequence of specific tasks.
2. Create a Permission Set for Each Task: Leverage the interviews and tools to identify relevant metadata for each Permission Set.
3. Create the Permission Set Group: Bundle all the task-specific Permission Sets into a “Pay_Commissions_PSG” group.
4. Test: Create a test user with the new Permission Set Group. Have the Finance team perform business acceptance testing on the Pay Commissions JTBD. If the Finance Profile changes, business acceptance testing must be completed for the other Finance roles.
5. Roll-out: Deploy to production, including new or updated User Access Policies.

Best Practices for Implementation

1. Communicate Clearly: Ensure all stakeholders understand the benefits and process of the transition.
2. Start Small: Begin with a single Job-to-be-Done to test your approach.
3. Document Everything: Keep clear records of your permission structure for future reference and audits. Elements.cloud is a great tool for documenting the Capability Model; the Jobs-to-be-Done; and the process, metadata, and permissions associated with each JTBD task. 
4. Regular Reviews: Set up a schedule to review and update your permission structure as your organization evolves.

Conclusion

We’ve laid out a structured approach to migrate from Profiles to Permission Set Groups using a Capability Model with Jobs-to-be-Done. This approach allows you to evolve your Salesforce security model at your own pace – one JTBD at a time. Using the tools provided by Salesforce and Elements.cloud, you can make this transition smoothly and set your organization up for a more secure and manageable future.

In Part 2, we’ll dive into the details of creating a Permission Set Group and Permission Sets based on the Finance “Pay Commissions” JTBD.