Remove Unused Profiles by Running User Reports

Few people I've spoken with realize that they are continuing to maintain profiles that aren't assigned to any users. As a result, everytime they create a field, record type, tab, app, page layout they are assigning controls to profiles that aren't being used by any users.

There's any number of reasons for this:

During the initial implementation, a decision was made to create profiles based on how the organization segments their business.  But not all of these profiles were ever used.

Active users were once assigned to the profiles but have since become inactive.  This could have happened when a division was let go.  It could also have happened when users were transferred to another group with different responsibilities. I can also happen when creating a lot of one-off profiles.

It's possible to report on profile assignments using user reports.  By running these reports, you can clean up un-used profiles that are assigned to inactive users.

HOW TO CONFIGURE

Under reports, create a new administrative > user report.

•       Type of report: matrix
•       Columns: Profile, Active
•       Group by: Profile (Y-axis) and Active (X-axis)
•       Summarize: Sum on Record Count
•       View: All Users
•       Duration: <No Dates>

Because the resulting report will only show profiles that are assigned, and it's possible to have more profiles than what have been assigned, it's a good idea to compare the count of profiles in the report to the count of profiles in the list view.  The difference will represent the number of profiles that are not assigned to active or inactive users.

Especially when used in conjunction with a governance policy for creating profiles, cleaning up unused profiles provides for an excellent way to keep profile proliferation to a minimum.

How to Create an Org Wide Maintenance Window using Login Hours

I traded tweets with Matt Lamb (@SFDCMatt) about this topic recently. It's a little known solution to a common problem: when performing org maintenance, how do you log out all users so that they can't make changes while the maintenance is being performed?

I think it's about time there was somewhere on the blogsphere I can point people to on how to use the workbench to change user's profiles *and* create an org wide maintenance window using Login Hours on profiles.

The reason why we can use Login Hours on profiles is that when you set the start and end times to the same hour in the day, it automatically invalidates the user's session and logs them out on their next click or API transaction. Changing a user's IP Range on their profile can also lock a user out, but only when their current session id expires which could be up to twelve hours after resetting the IP Range.

The basic solution outlined below will require changing everyone's profile to a 'Maintenance Window' profile with limited Login Hours. But it's important that you don't lose their existing profile assignments by accident since you will want to replace their 'Maintenance Window' profile with their original assignment once the window of time is complete. Also, while the solution below highlights changing profiles for users that share the same user profile, it's a good idea to consider doing this flow in chunks by user license and creating multiple Maintenance Window profiles, one for each type of license in your org.

Finally, it's important to note that simply inactivating users to accomplish the same thing is the wrong way to go since inactivating users can have a profound impact on your user's sharing and record assignments.


Steps to changing all User profile Ids except for the Maintenance Window Administrators:

1. Create a new ‘Maintenance Window’ Profile
1. Setup | Administration Setup | Manage Users | Profiles | New
2. Use any profile as a template (Read-Only or Standard User is fine since no one will have access during this time but if you want to be overly safe, revoke all permissions from the cloned profile before saving it) and name the new profile ‘Maintenance Window’
3. Create a Login Hours entry

1. Enter a time range other than the Maintenance Window
1. For instance, if the Maintenance window is Tuesday evening starting at 10:00PM and concluding by Wednesday Morning at 4:00AM, set the Login Hours to exclude this period of time or just set Login Hours from 12:00 am to 12:00 am every day of the week.
2. If a user tries to login during this time, they will fail. If they are logged in, the next action they take (click on a tab for instance), they will be automatically logged out
4. (Optional) Create a single IP Address Range Entry to an IP Address that no user may access such as 0.0.0.0 

1. Unlike Login Hours, this will not automatically log a user out, but will prevent any user with this profile from logging in     
5. (Optional) Edit the ‘Maintenance Window’ Profile
6. (Optional) Remove all permissions (Deselect all App Settings except Sales, Change all Tab Settings to Tab Hidden, Deselect all Object Permissions, Deselect all User Permissions)
7. (Optional) Remove all Apex Class and Visualforce page access
2. Copy the ProfileId from the newly created Maintenance Window profile. This may be done through the data loader or through the URL in the address bar by navigating to the Profile record.
  
3. Copy the UserIds for any user who will need to access the org during the Maintenance Window.  This may be done through the data loader or through the URL in the address bar by navigating to each user record.
4. Open Workbench (http://workbench.developerforce.com) and login as an administrator with ‘Manage User’ Profile Permission

5. Jump to: SOQL Query to extract your users

6. Select the User object and store your results locally in a csv file
7. Select the following columns
1. Id
2. LastName
3. FirstName
4. ProfileId 
8. Add the following constraint
1. WHERE Id != '<ID of any admin involved in the Maintenance window>'
9. Select the Bulk CSV radio button to make sure you get a CSV with all of your users you want to block from logging in during the Maintenance Window
10. The resulting SOQL query should look something like: Select Id, LastName, FirstName, ProfileId FROM User WHERE Id != '00530000001rI6A'

11. Select the Query button to extract your results
12. Download and save the CSV file as ‘MaintenanceWindowOriginal.csv’. This file is important in order to not lose your original profile assignments you'll need for the end of the maintenance window.

13. Change all ProfileIds to the ‘Maintenance Window’ ProfileId you’ve copied and save as a new file: MaintenanceWindowUpdate.csv

14. Update the Users in the Workbench  

15. Select the User Object and browse to your MaintenanceWindowUpdate.csv file

16. Create a mapping of CSV to User Object fields

17. Click Map Fields
18. Process records asynchronously via Bulk API and Confirm Update

19. Verify the Import was successful by navigating to the Manage Users screen and viewing the users.  All Users except the admins participating in the Maintenance window should be set to the Maintenance Window Profile.

20. Perform any necessary changes to configurations during the Maintenance Window, making sure not to delete any profile during the maintenance.
21. When you’re ready for users to have access again, load the MaintenanceWindowOriginal CSV back into the org using the Workbench and the same Update flow as you did to change their profiles the first time.
22. Verify the update was successful by navigating to the Manage Users screen and ensuring that the profiles were returned to their original state before the Maintenance Window.

You can use these same steps to mass update user's profiles using the API and a tool like the Workbench.

Create a governance policy for creating profiles

I spoke with an administrator last week who is responsible for enforcing her governance policy.  When anyone asks her to create a one-off profile, her standard response is that unless it falls into their existing segmentation (by region and then by business unit), she requires an SVP approval to create it. In other words, unless the request falls into her established governance policy that all parties in IT and the business have agreed to, the one-off profile won't be created.

This kind of response is not surprising considering how easy it is for profiles to proliferate based on these type of ad-hoc requests.  And once a profile is created and assigned to an active user, subsequent updates require the admin to continue to maintain these one-off profiles.

As a result, many admins I've spoken with have created a governance policy to control the number of profiles they need to maintain.  It should be a policy that all stakeholders including the business agrees to since it's possible that multiple administrators in different segments of the business will need to create one off profiles.  As a result, it takes guidelines, discipline, and auditability, to ensure that the policy isn't violated.

For example, you may have any number of page layouts for an object.  Your governance rule specifies that profiles will only be created for region.  As a result, you have your own Account page layouts for European and North American sales reps but not for English and French sales reps which would be a more granular distinction than what the policy allows for.

Advantages to a governance policy for creating profiles
Maintenance is manageable for a large implementation
Provides an advanced level of flexibility while maintaining a level of simplicity
Provides the ability to increase flexibility at a later date
Scalable for future phases
Ways to create this granularity may include by:

  1. Business Unit
  2. Department
  3. Region
  4. Country
  5. Industry
  6. Line of Business
  7. Product Line
  8. Product Portfolio
  9. Cost Center

It's good to limit the number of levels of granularity.  For instance, first by business unit and then by region. You may have a profile called Corporate Sales - Europe and another called Field Sales - Europe but it may not be beneficial to create a third level such as Corporate Sales - Europe - Financial Services unless absolutely necessary.

By setting the configuration granularity, there may still be exceptions.  And in the case of exceptions, it helps having an agreed to approval process (which may even be automated using custom objects and workflow approvals in the app). Having an established governance policy merely provides guidance to the analysts and architects in their planning and when additional approvals, such as in the case of exceptions, are necessary there is an established process to obtain that approval.