20 August 2013

A funny thing happened while uninstalling a package...

David Schach contacted me late last week with a problem - when trying to uninstall a package, he kept getting an error that permission sets from the package were assigned to a user. What was strange was that he had unassigned all of the users from the permission set. It was pretty easy to determine this, all you had to do was go to a permission set and click the Assigned Users button.

We met outside Starbucks this afternoon and worked together to see what was going on with the particular package. By using my favorite API tool, workbench, we were able to run the following SOQL query:

SELECT Assignee.Name, PermissionSet.Id, PermissionSet.Name
FROM PermissionSetAssignment

From this query, we found that there were actually some hidden permission set assignments. In this case, the packaged permission set had been assigned to a guest site user. Using workbench we deleted these assignments and tried the package uninstall process again. This time, it worked.

I dig connections like this because not only was I able to help, but now I have a fun use case to discuss with the packaging team around the uninstall process.

05 August 2013

Reduce Users with Too Many Administrative Rights

Giving out Modify All Data, Customize App, or Manage Users to other users is like giving the ultimate power in the salesforce.com universe.  And with total power comes... a lot of risk.

Ultimately, as organizations segment and divide into multiple organizations housed in a single org, the need to grant more delegated administrative rights grows exponentially.

There are options that you can explore:

  1. Modify All Records or View All Records instead of Modify All Data or View All Data
  2. Sharing instead of Modify All Data or View All Data
  3. Delegated Administration instead of Manage Users for specific roles or Customize Application for Custom Objects

The best way to proceed is to take away any of these administrative permissions from your users and let them try to perform their daily tasks.  You will quickly find where these permissions were needed and where you can compensate by providing alternative permissions or configurations.

For instance, one customer I worked with recently removed Modify All Data from a group of delegated admins.

One issue that came up was the need to use the data loader.  They solved this by downloading the client to a shared directory.

Another instance came up where delegated administrators needed to login as end-users; however, these admins could not have the Manage Users permission.  Using Delegated Administration groups, these admins were able to login and manage users for a role and the role's subordinates without requiring Manage Users (only View Setup and Configuration was required).

Ultimately, some tasks must still be performed by a System Administrator, but at least you can begin to whittle down the number of administrators who have too much access.