Copado Essentials Plus Edition has been carefully crafted to address a number of key challenges faced by many Salesforce development teams. After completing the setup of Essentials Plus, you and your team will enjoy the following benefits:

This document describes the process flow and a step-by-step guide to setting up Essentials Plus to manage your development pipeline. For Best Practices on how to optimize your use of Copado Essentials Plus, please refer to our guide linked above.

Sign in to Essentials with your Salesforce login using a common Production-level org across your team (anything with a login.salesforce.com URL). It is recommended that teams using Copado Essentials use their Production instance, as this allows the entire team to be populated after logging in for simple account management from the Team tab of Account Settings. For trial purposes and development teams, Copado Essentials does support account creation with Developer Edition orgs.

Copado Essentials does offer a 21-day self-activated trial for Essentials Free and Basic users, which can be initiated within the "Free Trial" tab in your environment. Take a look at these Help Docs for more information on how to initiate your trial and some example use cases. There are minor differences between an Essentials Plus paid account and an Essentials Plus trial account, which can be reviewed here.

Copado Essentials Plus offers two primary deployment methods to manage your DevOps process:

Work Items is ideal for teams looking to utilize in-app quality gates to deploy changes through a predefined set of environments. Work Items facilitates in-app approvals and merge conflict resolution, prior to simultaneously deploying changes to both the target Salesforce org and the target branch in your Git repository. Using Work Items, teams can manage several developer sandboxes within a single pipeline and easily initiate back deployments as needed. This method is a favourite among teams who aim to minimize the effort of deploying changes through multiple environments, impose quality gates, update Git in the background, and even designate a release manager, within a user friendly interface.

Deployments with Pull Requests offers developer oriented teams the ability to maintain the familiarity of creating and managing feature branches within a Git repository. This method, paired with webhook triggered CI Jobs offers a powerful combination to gain granular control of what is checked into your repository and deployed to your Salesforce environments. Teams who opt for this method often have a robust release process and need the flexibility that Git actions, CI Jobs, and external integrations can provide.

Check out the table below for a quick way to determine the best method for your team.

Sign in to Copado Essentials Plus with your Salesforce login using a common Production-level org across your team. After logging in, click Add Organization, and follow the prompts to connect each Salesforce environment that will be used as part of your development pipeline. When adding your orgs, make sure to correctly designate if the Salesforce environment is a production level org (signing in from login.salesforce.com) or a sandbox org (signing in from test.salesforce.com). Once the environment type and name has been input, click Authorize to sign in to the Salesforce environment. When successful, click Save, and repeat for all remaining orgs.

To help you easily get your team setup, or to take advantage of a common, shared Pipeline, Essentials Plus makes it easy to share orgs and repositories by prioritizing team collaboration. Review our Team Collaboration Help article to ensure your team has access to the orgs they need. Note that Org Sharing is by default set to "off". If you do not see the Share button in the Org setup please contact Copado Essentials Support to have this feature activated for your team.

Although each deployment method can be used without a Git repository for standard org-to-org deployments, it is highly recommended to incorporate a repository for auditability and security. Teams with a pre-existing Git repository can incorporate this into either deployment method, or following the steps below, you can easily seed a new repository for exclusive use with Copado Essentials Plus. For teams taking advantage of a pre-existing repository, this section may be omitted, however additional effort may be required to ensure synchronicity between Salesforce and your repository.

What you need to get started:

The first step in connecting a repository to Essentials Plus is to ensure that a repository has been created. Depending on the current status of your Salesforce environments, initializing a Git repository can be achieved in two ways. To initialize a Git repository for environments that are closely synced, a single main (often referred to as "master") branch can be seeded, followed by creating new Git branches as copies of the main branch. To initialize a Git repository for environments that are significantly out of sync, each Git branch created will need to be seeded individually to ensure branches most closely resemble their corresponding Salesforce environment.

Regardless of the deployment method chosen by your team, robust task management and tracking can be achieved through integrations with Jira and Azure Boards. Both integrations inherit the permissions and visibility assigned in the respective applications, and can easily setup with API Tokens following the guides listed above.

Salesforce developers and admins count on Copado Essentials Plus to quickly and reliably deploy changes from one Salesforce org to another. As teams grow in size and complexity, it is imperative for teams to go beyond org-to-org deployments and start thinking about how to formulate a consistent release process with built in quality gates in place. This is what Work Items with Pipelines was built for.

The Work Items with Pipelines method works like an org-to-org deployment except that deployed components are simultaneously committed to your Git repository to provide backup and version control. A Work Item is an encapsulation of a user story and its progression through a consistent change management process with approval, history, visibility and collaboration built-in.

A pipeline can be easily setup in just a few minutes by locating the Pipelines tab within your Account Settings, and clicking Add Pipeline.

For each Stage in your pipeline, enter the environment name and select the associated Salesforce org to act as the source environment. While updating the Pipeline, you have the option to include a Git repository for each stage following Development, and can enforce a mandatory in-app Approvals process. Orgs can be added and deleted from the pipeline quickly, and multiple pipelines can be created for varying use cases (Back promote pipeline, Hot Fix pipeline, process specific pipelines, etc.). Once you're satisfied with the pipeline setup, click Save, and it will be visible to all members within the team. For team members that need to use the pipeline, team owners and team leads of the associated Salesforce orgs and Git repository in the pipeline must share org access with other team members.

Any member of the team with an Essentials Plus license can create a Work Item. Work Items follow a User Story approach, where a "container of change" is created, after which changes can be bundled within this container and deployed through the Pipeline the Work Item is assigned to. Using this approach, changes are moved through lower, error tolerant environments, where they are ultimately refined and polished before reaching the live, error intolerant Production instance.

When creating a Work Item, "Title" and "Pipeline" are the only two fields that require values, although use of the other fields are highly encouraged for audibility and flexibility. The "Issue" field is designed for use with the Essentials Plus Jira or Azure Boards integration, however this can also serve as a tagging system in the event an unsupported ALM is used. The "Description" field can be used for internal collaboration and documentation, and the "Start from" field allows flexibility in the first stage of the pipeline by permitting you to deploy from any selected environment to the next stage in the pipeline. Once a Work Item is saved, you'll be directed to the Component Selection screen.

On the Component Selection screen, users can perform various actions with Work Items including comparing changes, adding components, sharing Work Items, managing merge conflicts, requesting Approval, initiating Robotic Testing and Static Code Analysis, or commenting on a Work Item.

Work Items metadata components list with pipeline stage progress at the top.

Work Items encapsulate the entire deployment process in a single process, seamlessly moving the Work Item between stages following a successful deployment. Version control can be easily integrated in the background (indicated by the icon within the pipeline), maintaining synchronicity when deploying changes between environments and committing to Git. Upon successful deployment to a shared environment, Back Promotions can easily be achieved by using the "Back Promote" button under the More dropdown menu, and in the event unexpected errors occur after a deployment, there are several options to rollback to previous versions (even without Git!).

As part of a sprint, multiple Work Items may be deployed to a Pre-prod environment with the intent to release them all at the same time. Fortunately, Essentials Plus offers an easy way to merge Work Items in the same stage for bulk deployment into a target environment. On the Work Items tab, a history of the most recent 100 Work Items will be displayed, which can be filtered by current stage, target, creator, etc. Here, you can select Work Items that are waiting to be deployed into a common target environment and merge them for a bulk release.

Teams that opt for the Deployments with Pull Requests method have additional flexibility in their pipeline to incorporate Git functionality that is otherwise missed with the Work Items method. With this method, teams can commit changes from a Salesforce environment to a feature branch within Git, after which merge conflicts can be managed within Git, and any other Git actions desired can be incorporated into the process. Following a successful merge of a feature branch into the target branch, CI Jobs can be configured to automatically deploy incremental changes to the corresponding Salesforce environment. Although this method requires more manual effort to move between environments (cloning deployments and recreating feature branches), this ultimately grants granular control over what is admitted into Git and Salesforce. Teams commonly use this method to deploy from lower environments to an upstream feature branch, then merge this branch to kick off a CI Job to push changes to the Salesforce environment (as shown below), however this method can accommodate a much more flexible branching strategy.

Note: To ensure changes merged into the target branch are automatically merged into the target Salesforce environment, a webhook triggered CI Job for this action must be setup prior to merging branches within Git.

Common Deployments with Pull Requests work flow:

The Deployment with Pull Request method deploys through your Git repository to allow creating a pull request before updating the target branch and org. This provides an opportunity to check for merge conflicts.

Unlike a Work Item, metadata added to a Deployment can be committed directly to a feature branch (or target branch, as performed during the Git Initialization steps above) for a flexible deployment work flow through Git. Using the Diff Key, metadata can be added to a Deployment and committed to a feature branch that is generated by Copado Essentials upon clicking "Commit to Git Branch". You can then click to "Review Changes" in Git upon success.

Within your Git repository, changes can then be reviewed and managed following any internal process that has been outlined by your team. When the changes are merged into the target branch, this action will act as the trigger to initiate a CI Job to pull the changes into the corresponding Salesforce environment.

Below is the CI Job that will has been triggered upon merging the newly created feature branch into the target branch. This merging action initiated the CI Job, incrementally deploying the changes that were just merged.

To increase efficiency and automate your Essentials Plus work flow, CI Jobs can be a powerful method for reducing repetitive actions and increasing oversight. For a detailed view of what CI Jobs can do, refer to our CI Jobs Overview article. However, to continue with the Deployments with Pull Requests method listed above, a CI Job is needed to pull newly merged changes from our target branch to our target Salesforce environment. To create this CI Job, move to the CI Jobs tab within Essentials Plus and click "Create a New CI Job". Depending on the goal of this CI Job, the source and targets will vary, but to continue with the work flow from above, the source of this CI Job will be the Git branch that you anticipate changes being merged into, and the target will be the Salesforce org that you want these approved changes to be automatically deployed to. Below, you can see the CI Job is set to pull newly merged changes from the UAT branch of the repository and automatically push them into the UAT org after the CI Job is triggered by a webhook. This effectively updates your Salesforce environments incrementally with each successful branch merge.

IMPORTANT: After saving, edit Deploy Options and change the Git Source option to deploy files committed since the last successful build, like below.

By default, the last successful build marker points to the head of the branch. If you click on Review Pending Changes, the queue should contain zero components following a successful deployment.

At this point, additional CI Jobs can be created for the remaining environments and branches in your work flow, where you can automatically trigger deployments into sandboxes and validations against Production. An example of the latter can be seen below:

As opposed to triggering a deployment into a risk intolerant environment, you can automatically check to see if changes merged into the Main branch of your repository would successfully deploy into Production with a Validation CI Job. If successful, this can be manually deployed into Production.

An incremental build contains only files committed since the last successful build which is indicated by a build marker. Every time a deployment is successful, the build marker is automatically moved to the head of the branch.

This means the pending change queue is reset after every successful deployment, and no manual intervention is required in general. However, if you ever need to change the build marker to a specific point, simply edit Deploy Options and point to the new commit ID. Note that for an incremental validate CI Job, a successful validation does not move the build marker automatically. The build marker for a validate CI Job is only moved when the equivalent deploy action is executed successfully.

A full profile file can contain 50k lines of xml, which makes it unfit for the purpose of source control driven deployments and merge resolution. In order to work with profiles effectively, commit only the base profiles when you initialize your Git repository for the first time. You can commit only the base profiles by creating a separate commit deployment from your Prod org to your Git repo and include only the Profile wildcard (excluding any other wildcards), like below. This way, the profiles will not carry any other related permissions.

After a few months of development, your profile files will eventually grow to a certain size. At that point, you can decide to trim the profile and bring it back to its starting baseline by repeating the above commit deployment, this time, edit Deploy Options and change the Git Commit option to Overwrite.

To Overwrite means that Essentials Plus will simply take the base profile files and overwrite the large profile files in your Git repo.

We recommend the use of Salesforce DX source format instead of the outdated Metadata API (MDAPI) source format for the following reasons:

Note that DX is a spectrum of technologies including a new code format, CLI, scratch org, source tracking, and packaging 2.0. At this stage, the only part of DX that we recommend teams leverage is the new code format. The remaining parts still need a more time to reach production maturity. Scratch org and packaging 2.0 requires a significant amount of upfront investment in breaking down your code into modules and the overhead of managing dependencies between these modules cannot be understated. Switching from MDAPI format to DX format does not change your development workflow. You can continue to develop in sandboxes (instead of scratch orgs) or use your favorite developer tools (VS Code, Illuminated Cloud, Welkin Suite, etc). All of these tools now support using DX format against sandboxes. To clarify, you can still successfully use MDAPI format within Essentials Plus, as we will continue to support both DX and MDAPI source format. It is important to recognize, however, that any deployment strategy that involves calculating differences (including Salesforce change management) will work more effectively when the content is broken down into smaller, more manageable files.

Using an incremental deployment strategy is a great way to speed up your CI builds. Occasionally, there could be specific scenarios where you might want to include certain files in your CI builds even if they have not been changed. This can be achieved by leveraging Essentials Plus CI Job Inclusion option.

Simply edit the Deploy Options, and enter paths for the files you wish to include in the CI Job build and these files will be included together with the result of the diff calculation.