Evolving Your Salesforce Security Model: Part 2

Creating a Permission Set Group for a Job-to-be-Done

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

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

We also discussed some tools from Elements.cloud that you can use to streamline the analysis and planning stages of the migration process.

Now we’ll show how we executed this process at Elements.cloud.

Mapping a Job to a Permission Set Group

Recall from Part 1 that our strategy is to

1. Identify a Job-to-be-Done.
2. Define the tasks required to do the job.
3. Create a Permission Set for each task.
4. Group these Permission Sets into a Permission Set Group that represents the job.

Case Study: “Pay Commissions”

In the Elements.cloud Capability Model, one of the Finance Jobs-to-be-Done is “Pay Commissions”. Let’s walk through the process for creating a Pay_Commissions_PSG Permission Set Group.

Identify the Tasks

Our Business Analyst meets with the VP, Finance and the Finance Analyst responsible for paying commissions. The analyst also meets with the Sales Operations Manager and Salesforce Admin responsible for the custom Commission Management application in Salesforce.

The result is an end-to-end process map that begins with activity on the Opportunity (assigning the Opportunity Team members and moving the Opportunity to Closed Won) and ends with a valid Commission Statement and payment. Figure 2 illustrates part of the end-to-end process and gives you a sense for the level of detail captured.

The “Pay Commission” job includes three Salesforce-related² Finance tasks

• Calculate commissions payable upon invoice (“invoiced commission”)
• Calculate commissions payable upon receipt of payment (“paid commission”)
• Calculate credit-driven commission reversals (“reversed commission”)
  

Create a Permission Set for Each Task

Map the Task and Identify Metadata Using Expert Interviews

Continuing the discussions with the Finance and Salesforce experts, the Business Analyst documents the detailed process steps for each of the three tasks and annotates them with additional documentation and linked metadata. Figures 3 and 4 illustrate the process steps for the invoiced commission task along with the documentation and Salesforce metadata associated with each step.

Identify Additional Metadata Using Salesforce Metadata Reports

The Business Analyst uses the Elements.cloud Custom Views of Metadata feature to begin understanding all the metadata that may be involved in the commission process.

This works best when your metadata has good, business-oriented descriptions. If your metadata does not, you can use this discovery process to update your metadata descriptions! Good descriptions are also critical for Agentforce and other AI tools that query Salesforce metadata.

Here’s an example of a custom view where the metadata’s Description includes “commission”. 

Identify Additional Metadata Using Dependency Analysis

Dependency analysis can help the Business Analyst identify metadata that may have been missed.

Most processes/tasks have some automation.³ The Business Analyst reviews those automations for dependent metadata that our Permission Set will need to include. In the case of the commissions process, there is a “Calculate_Commission_Line_Item_from_PE” Flow. This Flow automates the process in Figure 3 when an invoice is created.

There are two ways to do dependency analysis using Elements.cloud.

View dependencies in the Elements.cloud Dependencies tab

Have ElementsGPT export a csv of the dependencies

With ElementsGPT enabled, you can use “Ask Org Copilot” to generate a csv file of the metadata that a Flow uses⁴ with the prompt

Please create a CSV file that includes all metadata where the “{api name}” {metadata type} is the dependency target.

Here’s an example along with an excerpt from the Excel file that was generated

Create the Permission Set

In a full- or partial-copy sandbox (because we need to test the process with real data), we create a “Calc_Invoiced_Commissions” Permission Set based on what we’ve learned so far.

Here’s a snapshot of the Permission Set using the Elements.cloud Permissions Explorer:

With ElementsGPT enabled, you can also use “Ask Org Copilot” to create a csv file of everything that the permission set grants access to using the prompt

Please provide a CSV file with all the entities that are granted access by the “{api name}” Permission Set, including all available columns from the permissions file.” 

Here’s an example along with an excerpt from the resulting Excel file

This is handy if you need to produce access reports for audit purposes. Although not shown here, Permissions Explorer can also create “who has access to what” reports for audit.

Create the Permission Set Group for the Job-to-be-Done

After all our analysis was completed, it was clear that the process and requirements for calculating invoiced, paid, and reversed commissions were all the same, just triggered from different events. As a result, we created the following Permission Sets

• Access_Commissions_App – the application and tab access was refactored into its own Permission Set since it’s common across all the use cases.
• Calculate_Commissions – for the Finance “Pay Commissions” job
• Manage_Commissions – for the Sales Operations “Manage Commissions” job
• View_Commissions – for the Account Manager “View Commissions” job

For “Pay Commissions”, we created a Pay_Commissions_PSG Permission Set Group that included the Access_Commissions_App and Calculate_Commissions Permission Set Groups. This new Permission Set Group is assigned to the Finance Analyst in the sandbox.

Clone and Update the Existing Profile

To test the new Permission Set Group in the sandbox, we cloned the Finance Profile and removed the overlapping permissions from the Profile clone.

Have Business Users Test and Validate the Solution

We assigned the cloned Finance Profile and the new Pay_Commissions_PSG Permission Set Group to the Finance Analyst. The analyst then went through the commission cycle, testing all three paths (invoiced, paid, and reversed commissions). This is where any final missing permissions would be surfaced.

Removing those permissions from the Finance Profile might break permissions for other Finance users. It’s important for Business Acceptance Testing to have all the Finance roles test with the cloned Finance Profile. If other Jobs-to-be-Done are broken, the safest choice is to add the required permissions back into the Profile and address them when you migrate those Jobs-to-be-Done.

Deploy the Profile, Permission Sets, and Permission Set Group

Once the business has signed off on the changes, you can deploy the updated Profile, Permission Sets, and Permission Set Group to production.

In this Case Study, we did not discuss updating and deploying User Access Policies. If you use User Access Policies, you’ll want to update and test these during the Business Acceptance Testing and deploy them with the other changes. Aligning Permission Set Groups with Jobs-to-be-Done should make User Access Policies easier to create and maintain, especially if your User Roles are aligned with the roles in your organization’s Capability Model.

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.

Migrating from profiles to permission sets and permission set groups, doesn’t have to be a daunting task. Connect with our team today and discover how the Elements.cloud Permissions Explorer functionality, reduces compliance risk and streamlines the move to a more streamlined security model. 

Additional Context

1. RASCI-defined roles: Responsible, Accountable, Support, Consulted, Informed
   
2. There are additional tasks related to the actual commission payment that are executed in the accounting system. These tasks are omitted here for clarity. But note that this same process can be used for permissioning and security in non-Salesforce systems.
   
3. In case the automation fails or needs to be overridden, the Finance Analyst will need access to the same metadata as the automation.
   
4. In Elements.cloud, the source is “used by” the target. Equivalently, the target “uses” the source.