One of the primary use cases I hear with distributed administration is the ability to delegate customization access to some setup (metadata) components. This often includes components like objects, fields, record types, page layouts, workflow rules, etc. that the business wants to control and have a quick turnaround in production. The source of frustration for the business is that it usually has to wait for a bandwidth challenged System Administrator to make all of their changes. The challenge for the System Administrator is how to ensure that the business doesn't do something that could damage other users, such as deleting a field required in an integration.
While the Customize Application permission governs a user's rights to manage these setup components, and it's possible to distribute this right over a custom object using Delegated Administration, there aren't many options for managing custom components on standard objects or non-object configurations from setup that ensure the level of control and testing that most System Administrators require.
As an alternative to granting the Customize Application permission to the business users or having the business communicating all of their changes in detail for the System Administrator to make, it is possible to use a developer sandbox to distribute the rights necessary for business users or delegated administrators to manage their components. You would not want to give them a full sandbox copy because the System Administrator profile will ignore all sharing configurations and give those delegated administrators access to *all* data within the org.
When a business user wants to manage some aspect of the application, you would:
- Create a developer sandbox for the request (don't reuse a sandbox that was created for a separate purpose).
- Name the sandbox after the user/business group making the request.
- Activate the sandbox.
- Give the business user the System Administrator profile making them a delegated administrator over this one sandbox.
- Train the distributed administrator how to make changes in the sandbox and create a change set.
- Let the distributed administrator make changes to their sandbox setup.
- Have the distributed administrator upload their change set to production.
- Review the changes that the user has included in the change set to ensure they do not disrupt anything like an integration or Apex.
- Deploy the change set to production.
- Make any additional changes that weren't included in the change set (for instance, a change to the role hierarchy or sharing rules).
The advantages of this solution are:
- You can grant full administrative rights to a user in a controlled environment without giving them access to *all* data or full administrative rights in production.
- You can review any changes to ensure the integrity of the production org, which is a benefit to the distributed administrator who made the changes (after all, if something were to break as a result of the distributed administrator's changes, they may be affected as well).
- The change set remains active in the org for a period of time allowing for an audit of changes (beyond the setup audit trail).
- This process is an optimization over the existing one where you have to create an efficient communication channel for the business to describe all of the changes that need to be made. So a slight delay between when the delegated admin uploads their change set and when it's been reviewed/deployed, is still less time than if the delegated admin had to document all of the changes and communicate them, especially where the changes are routine (i.e. creating several fields or modifying a page layout).
The disadvantages of this solution are:
- There is a slight delay between when the business uploads the change set and when it gets deployed after being reviewed. While maintaining the integrity of the org make senses, it can be frustrating when the change is perceived by the business to be minor, such as adding a field or changing a field property on a page layout.
- Not all metadata is supported in the metadata API which means some manual changes may need to be made in the production org.
- To enable the distributed administrator to upload a change set, you need to give them full rights in that sandbox, including the ability to manage users or modify all data.