Skip to main content
All CollectionsSetup and IntegrationSetup Guides
Essentials Plus Edition Setup Guide
Essentials Plus Edition Setup Guide

Use this guide to determine which of the two Essentials Plus deployment methods is best for your team and how to set up Essentials Plus.

Garrett Meeks avatar
Written by Garrett Meeks
Updated over 5 months ago

Overview

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:

  • Complete version history for every changed component for compliance audits and troubleshooting

  • Merge Conflict Resolution in-app or facilitated through Git feature branching

  • One-click rollbacks for reduced Time to Recovery

  • Built in testing options to reduce Change Failure Rate

  • In-app Approvals process or the ability to manage approvals in Git

  • Allow multiple changes to be merged, validated and ready for release days

  • Support of incremental updates for complex metadata types, such as Profiles and Permission Sets

  • Enable multiple project teams to work in parallel using Project Manager

  • Support for commonly used ALM software like Jira and Azure Boards

  • Agile work flow to increase Deployment Frequency and reduce Lead Time for Change

  • A simple and intuitive UX that empowers admins to work with source control seamlessly in a declarative fashion

  • A fully streamlined release process that allows your team to focus on delivering business value faster

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.


Create an Essentials Account

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.

Note: To fully setup an Essentials Plus environment you'll need to have an Essentials Plus license and the Team Owner role within your account.

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.

Choose A Deployment Method

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

  • Work Items using Pipelines

  • Deployments with Pull Requests

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.

Note: It is possible for a team to use both methods simultaneously, through careful planning to avoid merge conflicts and asynchronous environments.

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

Work Items using Pipelines

Deployments with Pull Requests

  • Predefined linear pipelines

  • In-app Approvals and Merge Conflict Resolution

  • Little familiarity with Git UI

  • Accommodates flexible pipelines

  • Incorporates advanced Git functionality

  • Ideal for automated actions

Step 1: Add your orgs to Copado Essentials

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.


Step 2: Connecting a Git Repository to Essentials Plus

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:

  • A Git repository. Essentials Plus supports both cloud and on-premise Git repositories through Copado Version Control, Bitbucket, GitHub, GitLab, and Azure DevOps.

  • An Essentials Plus (or trial) account.

Initialize Your Git Repository:

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.

Git initialization for Synced Environments:

This method of Git initialization is suggested for teams whose environments are closely synched, meaning environments (sandboxes and production instances) contain minimal differences between one another. This is likely to be the case if sandboxes have been recently refreshed following completion of a release cycle.

  • Navigate to your Git provider and create a new repository within your account. Once the repository has been created, a branch is only created once files are committed to the repository, so metadata will need to be deployed from Copado Essentials Plus to create the main branch. Ensure that your permissions within Git allow for third party tools to perform actions. Whitelisting Essentials Plus may be required if you have an active Firewall in place.

  • Inside Copado Essentials Plus, navigate to the Organizations tab and click Add organization. Select the appropriate Git provider (e.g., GitHub, GitLab, Bitbucket, Azure DevOps, Copado Version Control) from the Type list, followed by giving your repository a name. Once selected, click Authorize, and follow the prompt to login to your Git provider. After logging in, click the blue “Select Repository” button next to Git repo URL to select the repository that you just created, then Save the organization.


    NOTE: If using an enterprise repository (i.e. on-premise), you will need to provide Copado Essentials Plus with a Git Repo URL where it can access your repo, and if using HTTPS, a Login Username and Password. If using SSH, you will need to provide your login username as well as configuring SSH keys within your Git provider settings. Copado Essentials Plus will generate the private and public keys for your use when you click the “Generate Key Pair” link next to SSH.

  • To seed the newly created repository, click the Deployments tab along the top, followed by “New Deployment” in the top right corner. Give your deployment a name (i.e. Git Init). Set your Source Org as the top level production org of your development pipeline, as this deployment will be used to populate the main branch of your repository and should mirror what is currently in Production. For the Target Org, set this as your Git repository and click Save. Note that a message appears below the Git repository selected as the target stating that "Copado will not directly commit to master. A new branch will be used to facilitate pull requests." By default, when Copado deploys to a Git repository a feature branch is created, however we will override this functionality within the Deploy Options for the explicit use of seeding a repository.

  • From the Add Components tab in your deployment page, click the component Type dropdown and select Wildcard (the component types are in alphabetical order). On the right-hand side of the component grid, click the Select checkbox that tops the column second from the right. You should see all of the wildcard components selected in this list.


    Warning: If you encounter the following error: "Error: Error while retrieving metadata from the source.org. LIMIT_EXCEEDED: Too many files in retrieve call, limit is: 10000" and my commit failed, you will need to break up your deployment of the wildcards into several smaller deployments as opposed to what was recommended above in selecting all the components in the list. Salesforce limits of metadata package zip size is 39MB.

    Here is one approach you can take to breaking up you deployment into three passes: Because there is no dependency issue when deploying to a Git repo, you can deploy in any order. For example, you can deploy the objects and fields in one pass and then deploy profiles and permission sets in the second pass, and then everything else in the last pass. You may, actually, be able to combine the second and third passes.

  • Next, navigate to the Deploy Options sub-tab. From here, scroll down to the bottom and click “Change”, then expand the page by click the gray “Advanced Options”. You should seen an option that says “Commit directly to the target branch main”, which will allow you to commit directly to the main branch of your repository (instead of a feature branch). Optionally, within this screen you can choose to seed your repository using either Metadata API or Salesforce DX format, however default behavior is to use Metadata API format.

  • Once selected, click "Save", and you're ready to hit “Commit to Git Branch”. This could take several moments depending on the size of your Salesforce org as Copado Essentials is migrating all metadata accessible through the Salesforce Metadata API to your new repository.

  • Since this action would've deployed all accessible metadata in your Salesforce environment to your Git repository, once completed you can click "Review Changes" to see a copy of all metadata in Git. As this method is for environments that are closely synced (if not identical) to Production, at this point you can clone the main branch of your repository for each of your Salesforce orgs that are part of your deployment pipeline.

    • For example, in a pipeline where development work is done in a sandbox and pushed to a QA/Pre-Prod environment, your repository should contain three branches in total--one for each Salesforce org. These extra branches allow for you to resolve any merge conflicts long before the changes reach your production environment or main branch.

  • This is is what your environment may look like if you are using Github (the format will be similar in other Git repositories):

  • From here, select the main branch button, type in the name of the branch you wan to create that corresponds to Salesforce environment (e.g. UAT), and click Create branch from 'main'.

  • Once a branch has been created to use with each environment, you can designate which branch to deploy to within a Pipeline, or with each Deployment.

  • On completion, your Organizations should be similar to the image below, where you have each Salesforce org connected to Essentials, along with the single connected repository that Essentials can reference for specific branches.

Git Initialization for Out of Sync Environments:

This method of Git initialization is suggested for teams whose environments are noticeably out of sync, meaning environments (sandboxes and production instances) contain significant differences when compared to one another. This is likely to be the case if there is in-progress work within developer environments. For this scenario, multiple "empty" branches will need to be created prior to deploying Salesforce metadata into them individually.

  • Navigate to your Git provider and begin the action of creating a new repository within your account. During creation, the repository must be created with the README file included with main branch creation. Typically, a commit action is needed to create a branch within a repository, however for this instance we are needing to create branches that are essentially empty. Creating the main branch with only the README file will allow for a branch to be created, after which the "empty" branches can be cloned before having each branch seeded with Salesforce metadata. Ultimately, this will allow for each branch to be seeded individually with the metadata that the branch corresponds with. Finalize the creation of your new repository with the README file included by clicking "Create". Ensure that your permissions within Git allow for third party tools to perform actions. Whitelist Essentials Plus may be required if you have an active Firewall in place.

  • Inside Copado Essentials Plus, navigate to the Organizations tab and click Add organization. Select the appropriate Git provider (e.g., GitHub, GitLab, Bitbucket, Azure DevOps, Copado Version Control) from the Type list, followed by giving your repository a name. Once selected, click Authorize, and follow the prompt to login to your Git provider. After logging in, click the blue “Select Repository” button next to Git repo URL to select the repository that you just created, then Save the organization.

    NOTE: If using an enterprise repository (i.e. on-premise), you will need to provide Copado Essentials Plus with a Git Repo URL where it can access your repo, and if using HTTPS, a Login Username and Password. If using SSH, you will need to provide your login username as well as configuring SSH keys within your Git provider settings. Copado Essentials Plus will generate the private and public keys for your use when you click the “Generate Key Pair” link next to SSH.

  • Navigate back to your repository. Since the main branch that was created will ultimately serve as the backup for only Production metadata, branches corresponding to all other Salesforce orgs need to be created. As the main branch is "empty", clone the main branch of your repository for each additional Salesforce org that is part of your deployment pipeline.

    • For example, for a three stage pipeline Dev -> QA/Pre-Prod -> Production, a branch will need to be created from main for both UAT and Dev, for a total of 3 branches. These extra branches allow for you to resolve any merge conflicts long before the changes reach your production environment or main branch, and serve as a backup for each environment when needed.

  • This is how it will look in Github with only a README file within the main branch (the idea is the same in other Git repositories):

  • From here, select the main branch button, type in your branch name (e.g. UAT), and click Create branch from 'main'. Notice that the branches being created only contain the README file as these will be specifically seeded from their corresponding Salesforce environments. This will ensure that the repository accurately reflects how each individual environment currently exists.

  • Once a branch has been created for each Salesforce environment, return to Copado Essentials Plus to begin seeding each branch using the Deployments method.

  • Under the Deployments tab, create a new deployment by clicking “New Deployment” in the top right corner. Give your deployment a name (i.e. Git Init). Select the Source Org as your Salesforce environment (i.e. Production, UAT, Integration, etc.) and Target Org as the newly created Git repository that you added in previous steps. Take care to choose the branch corresponding to the Salesforce environment selected as the source, and click Save. This step will be repeated for all Salesforce environments and their corresponding Git branches.

  • From the Add Components tab in your deployment page, click the component Type dropdown and select Wildcard (the component types are in alphabetical order). On the right-hand side of the component grid, click the Select checkbox that tops the column second from the right. You should see all of the wildcard components selected in this list.


    Warning: If you encounter the following error: "Error: Error while retrieving metadata from the source.org. LIMIT_EXCEEDED: Too many files in retrieve call, limit is: 1000" and my commit failed, you will need to break up your deployment of the wildcards into several smaller deployments as opposed to what was recommended above in selecting all the components in the list. Salesforce limits of metadata package zip size is 39MB.

  • Next, navigate to the Deploy Options sub-tab. From here, scroll down to the bottom and click “Change”, then expand the page by click the gray “Advanced Options”. You should seen an option that says “Commit directly to the target branch main”, which will allow you to commit directly to the selected branch of your repository (instead of a feature branch). Optionally, within this screen you can choose to seed your repository using either Metadata API or Salesforce DX format, however default behavior is to use Metadata API format.

  • Once selected, click "Save", and you're ready to hit “Commit to Git Branch”. This could take several moments depending on the size of your Salesforce org as Copado Essentials Plus is migrating all metadata accessible through the Salesforce Metadata API to your new repository.

  • At this point, you've completed the steps to seed the first branch of your repository, however this will need to be repeated for every additional Salesforce org and it's corresponding branch. Deployments can run concurrently, so repeat the Deployment setup and commit, changing the source org and target Git branch to reflect all other environments that will be utilizing the repository. Once a branch has been created to use with each environment, you can designate which branch to deploy to within a Pipeline, or with each Deployment.

  • On completion, your organizations should be similar to the image below, where you have each Salesforce org connected to Essentials Plus, along with the single connected repository that Essentials Plus can reference for specific branches.


Step 3: Implementing a Deployment Method

Incorporate an ALM Service:

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.

Work Items:

Configuring a Pipeline for use with Work Items

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.

Setting up your Pipeline

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.

Create a Work Item

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.

Deploying Work Items Through a Pipeline

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.

Deployments with Pull Requests:

Defining a Work Flow:

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.

Notes

  • In the diagram above, there are two main branches: Prod and QA. Any commits to the Prod branch will ultimately get deployed to your production org, and any commits to the QA branch will ultimately get deployed to the QA org. This requires CI Jobs to be configured prior to merging feature branches into target branches.

  • The CI jobs referenced in the diagram would be set up as incremental builds, which deploy only changes since the last successful build rather than deploying the entire branch. This helps to speed up deployments as well as minimize the risk of overwriting unrelated changes in production.

Deploying Changes to a Feature Branch:

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.


Step 4: Setting up CI jobs

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.

Understanding "Incremental Diff" deployments

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.


Step 5: Careful Considerations

Working with Profiles

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.

Salesforce Salesforce DX Source Format selection

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

  • Incremental diff deployment works better with DX source format. When you commit a single field, the diff would include only this single field in the incremental build. In the case of MDAPI format, since the field is part of a big object file, the entire object is included which contains a lot more than just the single changed field.

  • The breakdown DX code format makes merging easier.

  • DX source format is a prerequisite for developing Lightning Web Components.

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.

Understanding the Inclusion option

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.

Did this answer your question?