Deployment Permissions for Salesforce

Blue Canvas allows for easier deployment and tracking of changes in Salesforce, with new functionality to configure deployment permissions.

Last Update:
October 18, 2018

With this article, learn how Blue Canvas can help me keep track of changes made to my Salesforce system and how to configure deployment permissions on a per branch basis. I also learned how this feature can improve auditability and compliance with SOX regulations.

Here are our 5 Key Takeaways:

  • Blue Canvas can save up to 80% of the time it takes to deploy changes to Salesforce.
  • It can be difficult to track changes made by multiple stakeholders in Salesforce.
  • Blue Canvas automatically tracks changes and provides a log and commenting system.
  • With the new functionality, deployment permissions can be configured on a per branch basis.
  • This feature can improve auditability and compliance with SOX regulations.

Table of Contents

Using Blue Canvas for deployment can save you as much as 80% of the time it takes to deploy. But another key benefit is keeping track of changes to your Salesforce system. Knowing who changed what and when is essential for auditing and security as well as maintaining sanity.

Historically, Salesforce can be an opaque system with little visibility. It can be very difficult to know who is changing what and when in your Salesforce orgs, particularly when there are multiple stakeholders who have the opportunity to update and edit your Salesforce instance.

We were talking to a large healthcare company just last week and this was their challenge. They had a large number of “super admins” who had access to change multiple parts of the system. The development team was trying to get a better sense of who was making changes so they could bring some order to their deployment process.

That’s why Blue Canvas is proud to announce that we now allow you to configure deployment permissions from within Blue Canvas.

Setup Deployment Permissions in Blue Canvas

Blue Canvas already tracks who is changing what when automatically. It also provides a log and commenting system so you can see who is creating and deploying different requests.

With this new functionality you can specify which users can deploy to which sandboxes and environments on a per branch basis. For example, let’s say I want only my Account Owners to be able to deploy to production. You can now protect production deploys from being done by anyone except Account Owners who you have pre-designated.

In another example, I want my developers to be able to create pull requests to UAT but not deploy them. I can configure the system to allow just that. Developers can create a pull request for review into UAT, but only an Account Owner can actually accept the change and deploy it into production.


You might want to lock down production even more. In this example only Account Owners can even create deployment requests to Production.


And finally all my dev branches are open so that anyone can make various changes.

These permissions provides extra auditability and is great for SOX compliance. If you want to adopt a smoother release management process for Salesforce, you can leverage this feature to put enterprise security in play. To get access to this feature email

More like this