How To

[UPDATED] How To Use Flow and Process Builder to Temporarily Grant System Admin Rights to a User

Note: This has been updated to leverage Process Builder Winter 16 features. 

TempSystemAdminProcessBuilder

(I’d like to recognize Rakesh Gupta who is very well known in the Salesforce Community for his Process Builder/Flow expertise. Thank you for your guidance.)

A Salesforce user with a System Administrator user profile is an extremely powerful user. Basically, this user has the keys to your Salesforce org. S/he can manage users, modify any and all configuration/customization, has access to all data, and can modify ALL data in your org. That’s a lot of power and can’t be given away like candy, especially if you’re in a highly regulated industry.

Business Use Case: Addison Dogster is a system administrator at Universal Container. Sammy Sunshine is on the Salesforce release management team and has a read only user profile in Production. Sammy has an upcoming deployment off-hours and needs system admin rights to perform the deployment activities (including manual updates).

Solution: Addison was able to help Sammy by providing temporary system admin access during the designated change management window, with a solution that involves custom fields, workflow rule, field updatevalidation ruleflow and process builder.

Quick Steps:

  1. In the User Object, create three custom fields (Customize | Users | Fields). One will hold the system admin start date/time. The another will hold the end date/time. Lastly, we need a field to hold the user’s original profileID.

Note: Make sure to set FLS (field level security) to allow System Administrators to edit the fields, read only for everyone else.

System Admin Start Date/Time: This is the start date/time when the user should be updated to a System Admin user profile.

SystemAdminStart

System Admin End Date/Time: This is the end date/time when the user should be reverted back to their original user profile.

SystemAdminEndDate

Last Profile ID: This field holds the user’s original 18 character SFDC profile ID so we can restore the user back once the temporary system admin rights have expired.

LastProfileID

2. Add the three new custom user fields to the User page layout (Customize | Users | Page Layouts). I put them into a new section for Temp System Admin Access.

TempSystemAdminPageLayout

3. Create a validation rule (Customize | Users | Validation Rules) on the User object to require both the system admin start and end date/time fields if one is completed. (Thank you, Steve Molis, for your formula assist!)

ValidationRule

Note: You can create additional validation rules to ensure the end date/time is not before the start, etc. But for our purpose, I only want to make sure both are provided for the scenario.

4. Create a visual workflow (Create | Workflows & Approvals | Flows) that will update the user’s profile ID from the system admin user profile back to user’s original user profile. This will be invoked from the process builder you will create in the next step.

You need to first create the two variables (UserID and last ProfileID) that will be sent from the process builder to the visual workflow.

Flow-UpdateUserRecordLastProfileID-varLastUserID

Flow-UpdateUserRecordLastProfileID-varLastProfileID

This headless visual flow only has one step – record update. This should be”Set as Start Element.”

Flow-UpdateUserRecordLastProfileID

Save the flow.

On the flows screen, activate the flow.

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

This process will run on the User object.

TempSystemAdminUser

There is only one node criteria in this process which will grant the temporary system admin access at the start date/time and then restore it back to the original profile after the expiration date/time. We want this to execute for an active user where the system admin start date/time and system admin end date/time are not blank.

TempSystemAdminNodeCriteria.JPG

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

TempSystemAdminScheduledA.JPG

Now, we need to set up the action to change the user’s profile to System Administrator. (Note: This references the 18 character profileID.)

TempSystemAdminRecordUpdate.JPG

Next, we need to update the user record, specifically, the Last Profile ID field with the previous profile’s 18 character SFDC ID. We will accomplish this with a formula CASESAFEID (PRIORVALUE ([User].ProfileId).

TempSystemAdminPB-LastProfileIDUpdate.JPG

The second scheduled action will execute after the System Admin End Date/Time has passed.

TempSystemAdminScheduledB.JPG

The first action will restore the user back to his/her original profile. We will accomplish this by invoking the visual flow you created in previous step. This process will pass the UserID and the Last Profile ID values to an autolaunched flow so that the visual flow will use this information to update the profile ID to the value stored in the Last Profile ID field for the specified user.

TempSystemAdminInvokeFlow.JPG

For the second action, we want to reset the custom user fields (Last Profile ID, System Admin Start Date/time and System Admin End Date/Time) used for this process.

We will choose the Update Records option. On the Select a Record to Update screen, select the user record that started the process.

TempSystemAdminRecordtoUpdate

TempSystemAdminBlankOutFields.JPG

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 System Admin Start Date/Time and System Admin End Date/Time and save changes. (Note: You can test out your validation rule in this step by providing the System Admin Start Date/Time leaving the System Admin End 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 System Admin Start Date/Time has passed, confirm that the user’s profile has been updated to System Administrator.
  5. Once the System Admin End Date/Time has passed, confirm that the user’s profile has reverted back to the original profile, and all three fields (System Admin Start Date/Time, System Admin End Date/Time and Last Profile ID) are blank.

Deployment Notes/Tips:

  • The user custom fields, validation rule, process builder and flow (via flow definitions) can be deployed to Production in a Change Set.
  • After deploying the Change Set in Production, you need to activate the visual flow, process builder and workflow rule. They are deployed as inactive.
  • Verify whether the 18 character SFDC ProfileID for the System Administrator profile is the same as your sandbox. If it is not, you will need to update the SFDC user profile ID to match the Production ID by creating a new version of the process builder using the ‘Clone’ feature. Once you update the profile ID, you need to activate the new version of the process builder.
Advertisements

10 thoughts on “[UPDATED] How To Use Flow and Process Builder to Temporarily Grant System Admin Rights to a User

  1. Hi Jennifer!

    I’m very excited for you on your first Salesforce blog post. Very thorough step-by-step instructions to help others learn these declarative development techniques 🙂

    As you mentioned in the beginning, the System Administrator profile is a very powerful profile and should not be granted to users haphazardly. In this situation where a user occasionally needs elevated access to perform deployments in Salesforce, had you considered Delegated Administration (Setup | Security Controls | Delegated Administration) which allows you to grant someone administrative capabilities over specific custom objects?

    Regarding the swap profile trick (quite ingenious to be honest), had you considered using Permission Sets? Rather than swap the user’s profile you could use your automation to add then later remove a Permission Set that would grant the user very specific administrative powers without necessarily giving the user ALL keys to the kingdom, maybe just the keys to the guest house and not the mansion 😉

    For example, this permission set may grant the user the ability to “Customize Application” and “Deploy Change Sets” but not necessarily have the “Modify All Data” permission. And even if in your case the user does need “Modify All Data” permission, I’m a fan of the Permission Set route because if you did have any special validation rules or code, etc. that checks for the current user’s profile then the user’s profile technically never changes they simply were granted elevated permissions (via permission set) temporarily then those permissions were revoked.

    Just some food for thought, and my suggestions may or may not be applicable in your situation, I just wanted to share 🙂

    I look forward to reading more articles from you,

    Doug

    Like

  2. Thank you for the feedback. Our org does try and provide limited permissions via permission sets where possible. However, in this case, we determined giving temp system admin is the way to go.

    The Release Management team can make any needed change in Production as it is tied to a deployment that what I do not want to happen is we do a permission set that we think covers almost everything and then during deployment, they hit a road block and because we didn’t give Modify All (there are certain setup configuration that requires it, believe it or not), then that individual is blocked and would be trying to call a system admin to change his profile. Switching them to the system admin user profile and then monitoring the setup audit trail the next day is sufficient for us.

    Liked by 1 person

  3. Thank you for your great post!
    In regard to the grant permission option – That is only available is your company buys that specific license.
    Best,
    Lynn

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s