29 January 2013

Distributed Administration using Sandbox and Change Sets



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:

  1. Create a developer sandbox for the request (don't reuse a sandbox that was created for a separate purpose).
  2. Name the sandbox after the user/business group making the request.
  3. Activate the sandbox.
  4. Give the business user the System Administrator profile making them a delegated administrator over this one sandbox.
  5. Train the distributed administrator how to make changes in the sandbox and create a change set.
  6. Let the distributed administrator make changes to their sandbox setup.
  7. Have the distributed administrator upload their change set to production.
  8. Review the changes that the user has included in the change set to ensure they do not disrupt anything like an integration or Apex.
  9. Deploy the change set to production.
  10. 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:

  1. 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.
  2. 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).
  3. The change set remains active in the org for a period of time allowing for an audit of changes (beyond the setup audit trail).
  4. 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:

  1. 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.
  2. Not all metadata is supported in the metadata API which means some manual changes may need to be made in the production org.
  3. 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.

1 comment:


  1. Các ngươi theo ta dĩ nhiên là ta sẽ đem thẻ linh dành lại cho các ngươi, chỉ là các ngươi có nghe thấy tên Kiêu Hùng bang không? Có biết ai cầm đầu không?

    Nghe thấy Thanh Long bang Tả Long phút cuối có nhắc tới Kiêu Hùng bang, Nhạc Thành vẫn suy nghĩ ở trong lòng, chẳng lẽ Hân Nhi, Yên Nhiên, Đỗ Mật Nhi, Âu Dương Phiên Tình đắc tội phải người của Kiêu Hùng bang hay sao.
    đồng tâm
    game mu
    cho thuê phòng trọ
    cho thuê phòng trọ
    nhac san cuc manh
    tư vấn pháp luật qua điện thoại
    văn phòng luật
    số điện thoại tư vấn luật
    dịch vụ thành lập doanh nghiệp
    - Nhạc Thành sư huynh, Kiêu Hùng bang chính là thế lực số một số hai của học viên cũ, bang chủ tên là Lương Hùng, xếp thứ năm trên bảng, gần đây hình như đã leo lên vị trí thứ ba, một học viên mới của chúng ta là Lương Ngọc cũng gia nhập Kiêu Hùng Bang, nghe hắn gọi Lương Hùng là ca ca.

    Một học viên mới nói.

    - Cái gì, Lương Ngọc, Lương Hùng, Kiêu Hùng Bang, cái này khó trách.

    Trong mắt của Nhạc Thành bỗng nhiên xuất hiện lãnh ý, trong lòng minh bạch mọi chuyện, tất cả có lẽ là do Lương Hùng giở trò quỷ.

    - Được rồi, về sau các ngươi theo ta, sau đó chúng ta sẽ thành lập một bang, tên là Phá Quân Bang, Quách Dương ngươi trước hết làm trưởng lão, về sau những

    ReplyDelete

Note: Only a member of this blog may post a comment.