91��ɫ

I have been an #AwesomeAdmin for about 15 years now.��

This means that I eat, sleep and dream about the Salesforce platform and cannot wait to get my hands on the Release Notes every Spring, Summer and Winter to see what’s new (nerd alert!).

In my time as an SI Partner, I have solutioned across many aspects of the platform – Sales Cloud, Service Cloud, Marketing Cloud, Social Customer Service, Field Service, Nonprofits, Healthcare, Wave…whatever our Internal Users or Customers needed, I designed a solution and had a great time doing so.

But I would give anything to get back all of the late nights, weekends and holidays that I spent Deploying all of my #AwesomeAdmin solutions to Internal Users and Customers.

If only I had known about 91��ɫ!�� This is the only end-to-end Release Management Platform, built 100% native on Salesforce, so all of your DevOps Team Members can collaborate in one centralized Platform for all of your Salesforce Projects.

So, to all my dear #AwesomeAdmin Ohana, and as an homage to the legendary David Letterman, I give you my own Top 10 91��ɫ Features for #AwesomeAdmins!

#10 Release Pipelines

Native Process

Track in spreadsheets all work that has been completed in our lower-level Dev Sandboxes, what has been promoted/deployed to UAT, SIT or Integration Sandboxes and what has been promoted/deployed to Production.

91��ɫ Process

91��ɫ allows you to define as many Release Pipelines as your business warrants and then all of your Metadata changes are promoted/deployed across environments in the sequence you define.

‍

#9 User Story-Centric Model

Native Process

Maybe you are using standard Salesforce Cases with a User Story record type or maybe you have created a Custom Object to track Requirements.�� If you have a standard ALM Platform such as Rally, Azure DevOps or JIRA, they are either independent of Salesforce, or you have an AppExchange or custom-built integration.

91��ɫ Process

91��ɫ has taken the industry-standard ALM Tools such as JIRA and Azure DevOps as inspiration for our own User Stories to allow Scrum Masters and PMs the ability to fully document both Functional and Technical Requirements, Acceptance Criteria and common Agile attributes such as Epics, Sprints and Releases in one easy-to-use point-and-click page.

91��ɫ even offers an Unmanaged Package to manage and customize your bi-directional integration with JIRA or Azure DevOps!��

Using VersionOne, Rally, Agile Accelerator, ScrumDo or TargetProcess? We have uni-directional solutions for those too!

#8 The Commit Grid

Native Process

• Download the native Setup Audit Trail
• Filter Setup Audit Trail in Excel for specific Metadata Components, Last Modified By Users and Last Modified Date Ranges
• Manually create Change Set in Source Environment
• Manually add Metadata Components, one Metadata Component Type at a time to Change Sets
• Repeat for every Source Environment in your Release Pipeline as you Promote/Deploy to higher and higher Environments

91��ɫ Process

91��ɫ offers a gorgeous Commit Grid that allows you to leverage multi-column filters including:

• Component Name Contains
• Metadata Component Type (that’s right, you can, for example, filter for Apex Classes, Apex Triggers, Layouts and Custom Objects all at the same time!)
• Created By User
• Last Modified By User
• Created Date and/or Last Modified Date RANGE (yes! You can filter by a Created Date Range and/or a Last Modified Date Range!!!!)

‍

#7 Package Once, Deploy to All

Native Process

Manually create your Change Set(s) in every lower-level/Source Environment in your Release Pipeline each time that you need to Promote/Deploy to a higher Environment.

91��ɫ Process

Since 91��ɫ creates a unique Feature Branch in Git for each User Story (), then 91��ɫ creates your User Story Feature Branch once and that same Feature Branch is used for every level of Promote/Deploy of the User Story’s Metadata Changes all the way up your Release Pipeline!

The really slick point here too is that 91��ɫ enables #AwesomeAdmins to work seamlessly with git right within 91��ɫ (and native Salesforce!), by automatically handling all the git operations (checkout, merge, etc.).�� No worries about Command Line Interfaces for us #AwesomeAdmins – all git operations are managed by 91��ɫ behind the scenes and under the hood.�� 91��ɫ’s got your back!

One additional bonus to mention, as you move User Stories through your Release Pipeline, if a particular User Story is not complying with the QA standards or, for some other reason is not ready, you can decouple it from the Release and that User Story’s Feature Branch won’t be merged to the next Upper Environment.
��#6 Additional Git Operations

Because 91��ɫ leverages Git as our Version Control and single-source of truth for all Metadata Changes, whether Declarative or Code, our Commit Grid also allows these amazing additional Git Operations.

Recommit

Native Process

We are not perfect; sometimes, we grab the wrong Apex Class(es), Visualforce Page(s), Page Layout(s) or other Metadata Component(s) in our Change Set(s) today.�� To correct our mistake natively, we must:

• Paginate through however many Components are already in our Change Set one page at a time
• Manually remove each Component one page at a time, one individual component at a time
• Cull through segmented, paginated filters of Metadata Component Types to add in any missing Components one Metadata Component Type at a time, one page at a time

91��ɫ Process

With the 91��ɫ Recommit Git Operation, you use the very same awesome Commit Grid functionality to correct your error quickly, recommit/update the User Story Feature Branch, and, IF you really flubbed, you even have the option to Recreate the User Story’s Feature Branch!

Destructive Changes

Native Process

Sometimes in new Orgs, but more often in older Orgs, there is Metadata that we just plain need to delete, whether a Custom Field, a Custom Object, a Profile or Permission Set, a Page Layout, etc.

Native Change Sets do not allow Delete of Metadata so, today, I suspect many of you are doing as I once did, spending hours-upon-hours in each individual Environment manually deleting old Components after you have finalized all other Deployments from a lower Environment to an upper Environment

91��ɫ Process

With the 91��ɫ Destructive Changes Git Operation, you use the very same awesome Commit Grid functionality to perform Destructive Changes (aka Metadata Deletes) across all of your Environments as the User Story moves through its Release Pipeline!�� All with Points and Clicks!

Full Profiles and Permission Sets

Native Process

The two most frequent Use Cases we run into as #AwesomeAdmins are:

1. One of our Team Members Commits and/or Promotes/Deploys new Metadata Components to an upper Environment but forgets to bring along the Profiles and Permission Sets related to these new Components, so only the System Admins have access in the upper Environment
2. We are overhauling Profiles and/or Permission Sets, consolidating the existing or even creating net-new Profiles and Permission Sets in lower Environments and we have no easy declarative way to replicate our Profile and Permission Set changes/additions into the upper Environments

In order to update the upper Environment, as Admins we must rely on #AwesomeAdmin free declarative tools such as , or to document the Profile and/or Permission Set attributes left behind, but, at the end of the day, we are still left to manually replicate our Full Profile and Permission Set changes/additions in the upper Environments

91��ɫ Process

With the 91��ɫ Full Profiles and Permission Sets Git Operation, you use the very same awesome Commit Grid functionality to perform a Full Profile and Permission Set Git Commit that will be added to your User Story Feature Branch and will easily Promote/Deploy to each of your upper Environments as the User Story moves through its Release Pipeline!�� All with Points and Clicks!

��#5 Quality Gates

One additional bonus, before explaining the Quality Gates below, is that many of these Quality Gate Objects have a Master-Detail Relationship to the User Story and so, as an Admin, you have the ability to leverage features such as native Rollup Summary Fields to drive Salesforce Automation like a Validation Rule that prevents a User Story from being flagged for Promotion until the Rollup Count of Pull Requests with State = ‘closed’ is greater or equal to 1.

Static Code Analysis/Manage Apex Tests

Native Process

Hope that any Apex added or updated in your lower Environments are clean and follow best practices; wait until you attempt to Deploy to Production to see if you actually clear the 75% coverage required to deploy to Production and see if any of your other Metadata Components are impacted.

91��ɫ Process

Out of the box, 91��ɫ includes a free PMD Rule Set to identify common coding errors such as Excessive Apex Class Length, Deeply Nested IF Statements, SOQL Queries inside Loops, Missing Apex Test Class Assertions or If…Else Statements without Curly Braces.�� 91��ɫ Administrators can customize this Rule Set, including exclusion of Rules or the addition of your own Custom Rules.

Additionally, 91��ɫ also supports Static Code Analysis if your Organization already has the paid CodeScan (aka SonarCube) tool.

Static Code Analysis Settings are assigned to a Release Pipeline and can be run from an individual User Story or from an Org Credential and can also be invoked as a Scheduled Job that runs Weekly or Monthly.

Finally, 91��ɫ allows you to set minimum Code Coverage required per Environment and run native Apex Tests from an Individual User Story or an Org Credential; you can even Schedule Apex Tests to run Daily, Weekly or Monthly for an Org Credential.

Selenium (Automated Regression Tests)

Please do note: 91��ɫ Selenium Testing is an add-on module that requires additional licenses to be purchased beyond core 91��ɫ licenses.

Native Process

Natively, there is no mechanism for Automated Regression Tests.�� You may have Selenium in place (for example, Browserstack, Sauce Labs, CrossBrowserTesting), but it is most likely independent of Salesforce, unless you have built your own integration.

91��ɫ Process

When you purchase the add-on licenses for 91��ɫ Selenium Testing, you will be able to record, update, schedule and run all of your 91��ɫ Selenium Test Cases leveraging 91��ɫ Selenium Test Suites and 91��ɫ Selenium Test Groups to segment your 91��ɫ Selenium Test Cases for common Scenarios, Environments or Test Users.��

A simple Webhook will allow you to connect the 91��ɫ Selenium Recorder directly to your existing Selenium platform (for example, Browserstack, Sauce Labs, CrossBrowserTesting) in order to host the results (logs, screenshots or videos) of each test case execution.

Pull Requests (Git Peer Review)

Native Process

Natively, there is no easy way for Developers to review each other’s code and effectively collaborate nor provide feedback.�� Your Developers may already be using a Git Repository such as GitHub, GitLab or BitBucket and may be familiar with Pull Requests, but your Admins, PMs/Scrum Masters and QA Resources likely have little familiarity, nor visibility, on this collaboration and feedback.

91��ɫ Process

With 91��ɫ, Resources can create a Pull Request directly from any User Story, add collaborative or feedback Comments and save the new Pull Request to the User Story.

User Tests (Smoke/Manual Tests)

Native Process

Create a manual tracking solution in Excel, Google Docs/Sheets, Quip or SmartSheet to track all User Tests (Smoke Tests) and verbally review/prod Testers to make progress.

91��ɫ Process

Out of the box, 91��ɫ has Custom Objects for�� User Tests (Smoke/Manual Tests) including Test Scripts, Test Script Steps, Test Runs and Test Run Steps (aka Executions).

Because Capodo is built 100% native on Salesforce, you have full native Salesforce capabilities to add additional Automations, for example, you could create a Process Builder on Test Runs to notify the assigned Tester of a new Test Run Assignment via a native Task, Email Alert or Chatter Post!

Compliance Hub Scans

Please do note: Compliance Hub is an add-on module that requires additional licenses to be purchased beyond core 91��ɫ licenses.

Native Process

Natively in Salesforce, there is no built-in mechanism to monitor Declarative Metadata Changes and ensure that, as an example, an Admin does not grant a sensitive User Permission to Non-System Admin Profiles, or to ensure that an Admin does not inadvertently reduce the complexity of your Salesforce Password Policies, or even to ensure that Declarative Best Practices have been followed, for example, let’s make sure we don’t make a field required, then configure a default value for the same field.

91��ɫ Process

With 91��ɫ Compliance Hub, Administrators can configure Compliance Rules, which are Validation Rules against your Metadata Components using a very familiar UI.

Compliance Rules are put into Compliance Rule Groups and a single Compliance Rule Group can be assigned to one or more Environment, then run across an entire Assigned Environment or invoked for Commits and/or Deployments from individual User Stories.��

When creating Compliance Rules, the Admin can define whether a Detected Finding Aborts, Alerts but Proceeds, or simply Documents the Detected Finding.

‍

#4 Pipeline Manager

Native Process

Natively, to manage our Promotions, Deployments and Sandbox Syncs, we must rely��

Native Change Sets

• Native Sandbox Refreshes
• timing across Projects, Sprints and Releases are always an issue; often times there is just one critical piece of work actively in-progress in a Sandbox preventing a timely and regular Refresh Cadence…I have seen Sandboxes that have not been refreshed in 5 years
• timing against the 3x/year Salesforce Major Release Preview Instances is also frequently an issue
• must be built one Metadata Type Component, and one page within the Metadata Component Type List, at a time
• all corrections to a Change Set must be removed/added one Component at a time, per page within the built out Change Set
• Change Sets must also be re-built for each Upper Environment as we move through our Release Pipeline

91��ɫ Process

With 91��ɫ’s Pipeline Manager, the 91��ɫ Admin, Release Manager or PM/Scrum Master has a simple visual of all Environments within a particular Pipeline, easily identifying which Environments are ready for forward Promotion and which Environments are ready for Back Promotion – that’s right! No more Sandbox Refreshes!!!

‍

‍

The Release Manager can cherry pick which User Stories to forward Promote or Back Promote and the fields across the top of the User Story Grid are simply a Field Set from the User Story object, so it is 100% Admin-configurable!

Example Forward Promote:

‍

Example Backward Promote:

‍

‍

Mass Back Promote

Yes, it is true!�� With 91��ɫ, we can actually Mass Back Promote from an Upper Environment to all of the Lower Environments that are behind, with a minimum of 3 clicks!

In the Pipeline Manager, just click the Mass Back Promote button to begin:

The minimum 3 clicks a Release Manager needs to make are:

1. Source (Upper) Environment that we will Back Promote from
2. Project that contains the User Stories to Back Promote to the Lower Environments
3. Click the Promote or Promote & Deploy button

‍

‍

Above, there are actually 39 User Stories that made it to our Integration Sandbox, but have not yet been Back Promoted to any of our Lower Environment Dev Sandboxes.�� The Release Manager can further filter the list of User Stories, Cherry Pick and even pick-and-choose across the Lower Environments!

#3 Metadata Component Conflict Resolution

Native Process

Keeping our Sandboxes in sync is critical as our DevOps process matures because it helps us ensure that we minimize overlaps or conflicts in our Metadata Changes when we have multiple Developers and Admins working on common areas of our Salesforce Org.�� As previously mentioned, there are no native tools to help us avoid Metadata Component conflicts, and who among us hasn’t had an Apex Class or Page Layout suddenly, and without warning, change?

91��ɫ Process

With 91��ɫ Promotions, we leverage the User Stories’ Git Feature Branch(es) and, entirely behind the scenes, perform a Git Merge against the Destination Sandbox, Developer Org or Production Org’s Git Branch to determine whether or not Conflicts exist before we perform the final Deployment.

Auto-Resolve (Git Semantic Merge)

Out-of-the-box, 91��ɫ has been developed to automatically perform a Git Semantic Merge any time that a Merge Conflict is detected between a User Story Feature Branch and the Git Branch of the Upper Environment (Sandbox, Developer Org or Production) that we are attempting to Promote and Deploy into (in #AwesomeAdmin-speak, this would be an automatic override to the Metadata Component when there are conflicting changes made to the same area in, as an example, an Apex Class, Lightning Component or Page Layout across two different Environments in our Release Pipeline).

The default behavior for Auto-Resolve is that the highest User Story Number (which is actually the Native Name field as an Autonumber) wins when a conflict is detected and that User Story’s changes automatically override the lower User Story Number with the same Metadata Component presenting a conflict.

A 91��ɫ Administrator can override this User Story default on a Release Pipeline by following these instructions

Exclude from Auto-Resolve (Manual Resolution)

For each Release Pipeline within 91��ɫ, a 91��ɫ Administrator can also exclude Metadata Components such as Apex, Aura/Lightning Components and Page Layouts from Auto-Resolve so that you can assign a DevOps Resource(s) to review and correct the Conflict collaboratively.

‍

��Exclude from Auto-Resolve is also a configurable Multi-select Picklist, so the 91��ɫ Administrator can add Metadata Components to the Multi-select Picklist as your Business Use Cases warrant.

When Metadata Components have been excluded from Auto-resolve on a Pipeline, and a Merge Conflict is detected by a Promotion, your DevOps Resources with the appropriate 91��ɫ Permissions will be able to not only view, but actually correct, the Merge Conflict directly in 91��ɫ – all with points-and-clicks!

‍

Overlap Awareness across User Stories
Even before you Promote a User Story, 91��ɫ allows you to see, directly on your User Story, any other User Stories with the same Metadata Component, where a Merge Conflict is likely so that you can proactively assign DevOps Resources to collaborate and potentially resolve the conflict prior to Promotion.

‍

��
The only caveat here though is that the Pull Request will only show differences if at least one of the Overlapping User Stories has reached the master Git Branch (Production or Developer Salesforce Org).

#2 Deployment Steps

Native Process

Create a manual tracking solution in Excel, Google Docs/Sheets, Quip or SmartSheet to track all manual Deployment Steps that must be completed, including such Deployment Steps as:

• Migrate **Standard** Users – I have some pre-91��ɫ nightmares about having to create a high volume of standard Users in a Lower Environment, only to have to turn around and either manually recreate the Users again in the next Upper Environment or attempt to export the Users from the Lower Environment and hope that I can successfully import them into the next Upper Environment with transformations for unique values such as Username
• Freeze All Users during Deployment – no matter how many times I have communicated to Business Users that we will have a Deployment Window where they should not log in to Salesforce, and certainly should not make changes because of the significant post-Deployment data cleanup and shakeout required for a particular Deployment’s Metadata Changes, I always have Business Users who login during the Deployment Window, attempt to make changes to one or more records, then panic when something fails to work as expected. (S. in case you have not had the pleasure, it is a bit of a herculean task to bulk Freeze and Unfreeze Users through native mechanisms.)

91��ɫ Process

With 91��ɫ’s these and other historically manual Deployment Steps can be streamlined easily – mostly with points-and-clicks!

• Caveat – only Users with User Type = ‘Standard’ will be migrated
• – Now, with 91��ɫ, I can add two slick Deployment Steps with the help of one of my Developers (ok, I know I said with points-and-clicks, but once your favorite Developer gives you those 2 light scripts, you store them in a safe place, and now, with points-and-clicks, you drop them in as a Deployment Step!):
• Deployment Step with a small Apex Script that will run before the Git Metadata Deployment Step to Freeze all Active Users
• Deployment Step with a second small Apex Script that will run after the Git Metadata Deployment Step to Unfreeze all Active Users

#1 Native on Salesforce

Because 91��ɫ is built 100% native on Salesforce, you have at your fingertips all of the amazing native Salesforce features to leverage directly on the 91��ɫ application.�� Some examples of common native Salesforce features leveraged include:

• Validation Rules
• Process Builder/Workflow Rules/Flows
• Approval Processes
• Add your own Custom Fields to objects such as 91��ɫ’s User Stories
• Page Layout Customizations
• Lightning Page Customizations
• Full Reports and Dashboards Capability on 91��ɫ Objects, Records and Fields
• Compatibility on both Salesforce Classic and Lightning

Additionally, the 91��ɫ Development Team has been extremely thoughtful in their construction of our application, for example, having limited Visualforce Page overrides, and, in the instances where we do use Visualforce, we also include, more often than not, native Field Sets, so that you can control the User Experience.

‍