Temporarily Remove a Permission Set w/ Process Builder & Flow

For those Salesforce organizations, especially those who store PII (personally identifiable information) or PHI (protected health information) data, security requirements may dictate that Salesforce access is locked down and users are to only use SSO (single sign-on) to authenticate into Salesforce. However, having the “Is Single Sign-on Enabled” system permission does result in some limitations especially for system administrators or business power users. Apex Data Loader and many third party tools such Eclipse, Snapshot, etc. will not work with Single Sign-on. For this reason, rather than force Single Sign-on on the profile, consider assigning a permission set with the system permission “Is Single Sign-on User” instead to give users the flexibility of using these tools, as needed.

Business Use Case: Addison Dogster is a system administrator at Universal Container. Universal Container users should use SSO to access Salesforce with exceptions granted to use tools with Salesforce. Sammy Sunshine is a business power users who on a monthly basis needs to update certain Salesforce records in mass.

Solution: Addison is able to meet the Information Security access requirements and allow Sammy to use Data Loader, as needed, through automation using a permission set, custom fields, validation rule, visual workflow and process builder. While Addison could’ve manually removed and assigned the SSO User permission set to Sammy’s user record, Addison didn’t want to forget to add the SSO User permission set back in.

Quick Steps:

1. In Manage Users | Permission Sets, create a permission set with the system permission “Is Single Sign-on  Enabled”. For this example, we will call it the “SSO User.”
2. In the User Object, create three custom fields (Customize | Users | Fields). One will hold the SSO temp removal start date/time, another the SSO temp removal end date/time. Note: Make sure to set FLS (field level security) to allow the proper profiles to edit the fields, and read only for everyone else.

SSO User PS Removal Date/Time: This is the start date/time when the user’s SSO permission set is removed from their user record.

SSO User PS Reactivation Date/Time: This is the end date/time when the user’s SSO permission set will be reverted back to their user record.

3. Add the two new custom user fields to the User page layout (Customize | Users | Page Layouts). I put them into a new section for Temp SSO User Removal

4. Create a validation rule (Customize | Users | Validation Rules) on the User object to require both the SSO User PS Removal Start/Date SSO User PS Reactivation Date/Time fields if one is completed. Here is the formula (courtesy of Mr. Steve Molis):

5. Create two visual workflows (Create | Workflows & Approvals | Flows). One will remove the SSO User permission set and the other will assign the SSO User permission set. These will be invoked from the process builder in scheduled actions you will create in the next step.

Flow #1: Assign SSO Permission Set:

A. You need to create a variable to contain the User’s ID (varUserID) that will be sent from the process builder to the visual workflow.

B. This auto-launched visualflow only has one step – Record Create. You need to create a new record in the PermissionSetAssignment object.

The AssigneeId will be set to the UserID that is sent from Process Builder.

The PermissionSetId is the SFDC ID associated with the SSO User permission set.

This Record Create should be “Set as Start Element. 

C. Provide a name for your flow and ensure that the type is auto-launched flow.

D. Save the flow.

E. On the flows screen, activate the flow.

Flow #2: Remove SSO Permission Set:

A. You need to create a variable to contain the User’s ID (varUserID) that will be sent from the process builder to the visual workflow.

B. This auto-launched visualflow only has one step – Record Delete.

The AssigneeId will be set to the UserID that is sent from Process Builder.

The PermissionSetId is the SFDC ID associated with the SSO User permission set.

This should be “Set as Start Element. 

C. Provide a name for your flow and ensure that the type is autolaunched flow.

D. Save the flow.

E. On the flows screen, activate the flow.

6. Create the process builder (Create | Workflows & Approvals | Process Builder)

This process will run on the User object.

There will be only one node with multiple scheduled actions.

Criteria Name: Temp Remove and Assign SSO User PS

Criteria for Executing Actions: Conditions are Met

Set Conditions:

[User].IsActive Equals Boolean True

[User].SSO_User_PS_Reactivation_Date_Time__c IsNull Boolean False

[User].SSO_User_PS_Removal_Date_Time__c IsNull Boolean False

Conditions:

All of the conditions are met (AND)

Advanced:

Do you want to execute the actions only when specified changes are made to the record? Checked

We want this action to execute after the SSO User PS Removal Start Date/Time has passed, so we need to set the time for the scheduled action accordingly.

This process will pass the UserID value to the Remove SSO User Permission visual flow to remove the user from the permission set.

For the second scheduled action, we want to reassign the SSO User permission set. However, let’s not stop there. Let’s also blank out the previously set SSO User Permission Set fields (SSO User PS Removal Date/Time and SSO User PS Reactivation Date/time) used in this process so we start fresh for the next time.

We want this action to execute after the SSO User PS Reactivation Start Date/Time has passed, so we need to set the time for the scheduled action accordingly.

This process will pass the UserID value to the Assign SSO User Permission visual flow to assign the user from the permission set.

Additionally, we need to update the user record to blank out the fields.

Activate the process builder.

That’s it. Congrats, you’ve implemented the solution!

Now, before you make the changes in Production, you need to test your process.

1. Navigate to a user record.
2. Update the SSO User PS Removal Date/Time and SSO User PS Reactivation Date/Time fields and save changes. (Note: You can test out your validation rule in this step by providing the SSO User PS Removal Date/Time leaving the SSO User PS Reactivation Date/Time blank and saving the changes and vice versa. You should see the error message in both cases.)
3. Go to Create | Workflows & Approvals | Flows, you see the scheduled action records under the Paused and Waiting Interviews section of the Flows screen.
4. Once the SSO User PS Removal Date/Time has passed, confirm that the SSO User permission set has been removed from the user’s record.
5. Once the SSO User PS Reactivation Date/Time has passed, confirm that SSO User permission set has been assigned to the user, and the two fields (SSO User PS Removal Date/Time and SSO User PS Reactivation Date/Time) are blank.

Deployment Notes/Tips:

• The permission set, user custom fields, validation rule, process builder and visual workflows can be deployed to Production in a Change Set.
• Since the flow referenced the SF ID of the permission set which is newly created in each environment, you will need to update the permissionsetID accordingly in your visual flow.
• You need to activate the visual flow and process builder. They are deployed as inactive.
• Don’t forget to assign your Production users to the SSO User permission set.

Note: You can create an automated process using a modified version of the above process builder and visual workflow. The process builder will be set when a user record is created, executes all the time for an active user to immediately assign the user the SSO User permission set.