I recently finished a deployment that represented a first for me, which also means I learned some new lessons that I’d like to share.

The scenario

Because of a super restrictive data security setup, I, as the consultant, only had access to a sandbox. Production access was limited to a select group of internal users.

The dilemma

What is the best way to manage deployments and live changes when you don’t have access to the destination org?

My first finding

If you’re a Salesforce admin like me, you probably have gotten into the habit of creating, uploading and deploying your own change sets. You probably also have encountered validation errors which require the change set to be updated.

When you’re managing your own change sets, those changes can usually be made on the fly and re-uploaded. But when there is split access, troubleshooting those errors takes on a whole new meaning.

What I’ve found is helpful to quell this issue, is creating much smaller change sets. Unusually create a change set and throw all changes into it in order to deploy one time. In this scenario, though, it’s been most helpful to have very small and specific change sets, each addressing a particular feature. This way, if something fails validation, I can immediately target the feature of that change set rather than having to find a way to pinpoint the issue.

My Second Finding

The biggest deployment issue we’ve seen involved folder sharing. Since I’m a User in the sandbox only, and a folder is shared with me, upon validation, Salesforce will look for my user in Production. It’s not there, though, and that causes the error.

To resolve this, just make sure that any folders you create (or at least before you upload from the sandbox) are shared with a user, role or public group that exists in Prod. A workaround that we’ve done is to set them all to “All Internal Users = View” in the sandbox, upload and deploy as such, and then reconfigure sharing in PROD to account for the real User base.

As the implementation consultant, you’ll usually have admin access to Production but there are scenarios in which you won’t. This will create an additional challenge in order to manage, but if you follow these tips from the start, there’s no reason your deployment shouldn’t go smoothly.