Blue Canvas allows for easier deployment and tracking of changes in Salesforce, with new functionality to configure deployment permissions.
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:
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.
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 email@example.com.
How Sysco's team of 40+ developers and admins support a complex Salesforce release flow with Blue Canvas.
Our latest feature offers proactive suggestions so you can avoid dependency errors and better understand relationships between your Salesforce objects.
From your sandbox to a git repository in less than a minute
Why Salesforce DevOps is more than just hooking up a git repo to a Salesforce org
Diving into what it takes to smoothly merge work across Salesforce orgs