Not everything is deployable automatically in Salesforce - here’s how Blue Canvas helps teams manage the manual steps.
Though the Salesforce Metadata API can do wonders, unfortunately there are still manual deployment steps required for most complex Salesforce releases. The API cannot handle everything and in some cases teams don’t want it to. Some changes like Web-to-Lead, Quote Templates, Site.com, Automated Case User Settings are simply not supported in the Salesforce Metadata API. Others like Profiles and Permission Sets are, but still are difficult to automate, diff, compare and deploy.
Accordingly, many of our customers still have fairly sizable checklists of tasks that need to be completed pre- and post- deployment before they can call a release a success.
After watching our users struggle with coordinating these steps, especially in large orgs, we’re excited to announce that you can now create checklists in your Blue Canvas stories for tracking and coordinating the manual steps in your Salsforce release process.
Blue Canvas supports Markdown in the Description field for Stories (i.e. Deployment Requests). Users can leverage Markdown to create custom checklists that can be leveraged to track pre- and post-deployment steps.
But it’s more than just Markdown, Blue Canvas interacts with each checklist on the backend to keep track of the status of a task. As you check off boxes in your Stories, the status of the ticket is updated. You can even mark the manual side of a deployment as “Complete” just as you would in a ticket on any other ALM tool like JIRA.
Take a major release as an example. Blue Canvas allows users to release multiple Stories at once in a coordinated Release. It can be useful to leverage manual checklists to ensure that all the manual steps associated with the release are tracked and understood for accountability and completeness.
First, we can create the release in Blue Canvas. We can then assign manual steps to each member of the team to add their Stories to the release.
When they are done they can check off their box. A release manager now know who has not yet finished pinning their Stories and can reach out accordingly. They can also give status updates to other stakeholders based on the status.
The release can be submitted for validation and testing once the entire chain of manual steps is complete and we know we have a full Release candidate. You can then of course deploy as usual using Blue Canvas and move on to your post-deployment steps.
One great thing about Markdown is that it’s incredibly flexible. We built it this way because we know that teams have different processes for managing manual steps and Markdown offers complete flexibility.
The Description field is really important for Stories. Teams don’t want to just know “what” changed and “who” changed it. They need to document the reasons “why” different parts of a Salesforce system are changed. And the Description field provides teams with a simple and easy way to continuously document their changes as they make them. This spares organizations from having to do annoying and expensive audits every few years.
We’re excited to announce that in addition to this release of pre- and post-deployment step tracking in Blue Canvas, you can generally use Markdown to style and annotate your stories.
You can add headings, checkboxes, columns, links and use font formatting like bold, italics and underlining.
Now that this feature is live and in GA use for all of our customers, we’re excited to offer a sneak peak at what’s next.
We are currently working on the ability to assign Stories to other users in the system so that different tickets can be the primary responsibility of different users.
We are also working on @ notifications to better coordinate and assign different steps for users.
How to rollback a Salesforce change using Git without having to use the command line.
How Blue Canvas helped Twilio save 2–3 days each sprint and enabled the team to grow quickly.