You'll likely make numerous enhancements to your Salesforce instance over time to maintain and improve its functionality. These changes may range from minor updates to significant new application development initiatives.

Regardless of the scale, deployment is the common final step where these changes go live. It's a critical phase, and following best practices ensures your deployment is smooth and successful. This guide outlines deployment methods and provides a comprehensive set of best practices.

What is Deployment in Salesforce?

Deployment refers to the process of releasing applications, modules, updates, or patches to users. The effectiveness of your development, testing, and release strategy directly impacts adaptability and user satisfaction.

A Salesforce org (short for organization) is a unique Salesforce environment tailored to a specific tenant. These terms—org, organization, and environment—are used interchangeably.

Different Deployment Methods

Salesforce supports various deployment options:

Force.com / Eclipse

• A popular Eclipse-based IDE for Salesforce development.

• Synchronizes metadata between orgs.

Limitations:

• Unstable on Windows with large component volumes.

• Manual addition of dependencies.

• Destructive changes are supported but cumbersome.

Change Sets

• Point-and-click interface for metadata migration between connected Salesforce orgs.

Limitations:

• Restricted to connected orgs (e.g., sandbox to production).

• Not supported in Developer editions.

• No support for destructive changes.

Force.com Migration Tool (ANT)

• Command-line tool that uses metadata API for deployments via scripts.

Limitations:

• Manual editing of XML files is required.

• All dependencies must be manually added.

Salesforce Deployment Best Practices

Before Deployment

1. Plan Thoroughly: Coordinate deployment across multiple sandboxes with a detailed, shared plan.

2. Avoid Development in Production: Use sandboxes to replicate the production environment and test changes.

3. Backup Your Org: Export production data and metadata to ensure you can revert in case of issues.

4. Conduct End-to-End Testing: Use the Apex framework to verify code quality, functionality, and coverage (minimum 75%).

5. Implement Version Control: Track changes, manage branches, and enable collaboration using tools like Git.

6. Create a Release Strategy: Define release cycles, approval workflows, and rollback procedures.

7. Adopt CI/CD Practices: Automate integration, testing, and deployment to reduce risk and accelerate delivery.

8. Disable Conflicting Components: Temporarily deactivate rules, flows, and triggers that may block deployment.

After Deployment

• Validate Functionality: Confirm all changes work as intended and perform post-deployment testing.

• Reactivate Rules and Workflows: Restore any deactivated components to ensure business logic is reinstated.

What Can AutoRABIT Do for You?

AutoRABIT's release management solution streamlines deployments by offering:

• Automated transfers of metadata and Apex components.

• CI/CD workflows integrating user stories, version control, and sandbox environments.

• One-click deployments across environments.

• Rollbacks for failed or erroneous deployments.

• Comprehensive deployment logs and validation reports.

• Automated removal of incompatible metadata to prevent failures.

Deployment Types:

• Sandbox-to-sandbox

• Deployments via AutoRABIT builds

• Package.xml-based deployments

• Reuse of previous builds for new targets

• Revision-based deployments from version control

Conclusion

Deployments between Salesforce environments can be complex and resource-intensive. Choosing the right tools and following best practices—such as those supported by AutoRABIT—can streamline your process, minimize risks, and enhance deployment success.

Registering a Version Control Repository

1. Ensure user credentials are stored in the Credential Manager section of AutoRABIT with the Credential Scope set to Private. This enables the identification of individual users during code check-in.

2. When registering a Bitbucket repository, do not include the username in the repository URL. Incorrect Example: https://John@bitbucket.org/Repos/bitbucket-testcases-repo.git

3. Verify that all users have mapped their credentials for the target branch via the My Profile section before using it.

4. Create Branch Types (e.g., Dev, QA, Pre-Prod, Production) during branch creation. This helps to clearly identify From and To branches for Merge and EZ-Commit processes.

CI Jobs Related

1. Distribute CI Jobs Evenly: Schedule jobs across different times to avoid delays and reduce load, especially in SaaS environments.

2. Exclude Unnecessary Metadata Types:

   • Globally: Navigate to My Salesforce Settings in the My Account page under Admin and select metadata types to exclude. This applies to all future CI jobs.

   • Job-specific: In the BUILD section of the CI job, use Exclude Metadata Types to define exclusions for that job only.

3. Remove Login IP Ranges: Enable this in the Additional Profile Packaging Options under the Build section to avoid overriding whitelisted IP ranges in Salesforce.

4. Use Incremental Builds instead of Full Builds:

   • Only deploys delta changes (avoids redundant deployments)

   • Prevents governor limits from being exceeded

   • Skips execution if no changes are detected

5. Manage Destructive Changes:

   • Select Prepare Destructive Changes in the Build section

   • Select Run Destructive Changes in the Deploy section

   • Ensures deleted metadata components in the branch are also removed from the destination

6. Set Baseline Revision: To fetch changes from a specific revision onward, configure the Baseline Revision during CI job setup. Example: If the baseline is set to 9, changes from revisions 10 onward will be fetched.

Merge Functionality Related

1. Resolve Merge Conflicts Immediately: Do this before any other commits are pushed on the same files to avoid cascading conflicts. If resolution is delayed, create a new merge request first to retrieve the latest conflict set.

2. Prefer Entire Branch Merge: This avoids missing revisions during merge and maintains a full trace/log of merge actions compared to Single Revision, Release Labels, or Commit Labels.

External Commit Related

• Adopt a standard commit message format for easier tracking and traceability. Recommended Format: <ProjectName#SPRINT#UserStory#Module#DevName#>

Best practices for performing CI/CD based on Version Control are outlined below.

1. Automatic Incremental Deployment

Usage: Any Test Environment

Overview: Can be used for staging/production environments if sufficient test automation is in place. Typically triggered by a merge into master that runs a deployment to Staging, executes a full regression test suite, and only deploys to Production if all tests pass.

Benefits:

• True Continuous Integration

• Low maintenance

• Full control via Git (Agile AF)

2. Manual Incremental Deployment

Usage: Environments with scheduled deployment windows (e.g., UAT), or for deploying merged code from a dev branch to dev orgs.

Overview: Similar to Automatic Incremental Deployment but without the on-commit trigger.

Benefits:

• Low maintenance with better control over schedule

• Enables developers to deploy to dev orgs without altering baseline revisions

3. Pull Request Validation

Usage: Environments requiring stable testing windows (e.g., UAT) or deploying merged code to dev orgs.

Overview: Requires Pull Request Support plugin. Must be paired with a deployment job to maintain validation org synchronization with the upstream branch.

4. Continuous Validation

Usage: Validate full release packages alongside CI deployments in test environments.

Overview: Can be scheduled or triggered on-commit depending on validation time and commit frequency. Ideal for dedicated environments without dev access.

Limitations:

• Manual deployment needed to sync with Production

• Manual baseline revision updates required

• Risks if manual pre-deployment steps are involved; frequent smaller releases mitigate this

5. Automatic Validation

Usage: Production validation during early stages of staging or regression cycles.

Overview: Combines Automatic Incremental and Continuous Validation; triggered on commit or post-activity and performs a validate-only build.

Limitations:

• Manual deployment needed post-release to sync with Production

• Requires manual baseline update

• Risk of failure with manual pre-deployment steps

6. Backup

A scheduled job that pulls changes post a given date into a backup repository.

Important Note: Not a replacement for Branching Baseline. Relies on modification date and is subject to API limits. Should supplement but not replace periodic manual execution of Branching Baseline.

7. Test

Executes functional tests (e.g., Provar, AccelQ) independently of code deployment.

Usage: Useful for conditional execution (e.g., run tests post-data migration or before another deployment).

8. Custom Features

Unit Tests

Defaults:

• Production orgs: RunLocalTests

• Sandbox orgs: NoTestRun

Custom Feature: RunTestsBasedOnChanges generates input dynamically for RunSelectedTests based on mappings from Admin > Salesforce Org Mgmt.

Important Note: Mapping updates only when a CI Job is manually triggered with Run Code Coverage enabled. Frequent updates needed via manual/scheduled jobs (e.g., weekly). Concurrent deployments or validations during test runs can corrupt data.

Rollback

Usage: Only in Stage/Production.

• Lower environments should use Git-based rollbacks.

• In Production, enables immediate reversion after detecting critical issues.

• Validate rollback packages in Stage to identify potential rollback-specific errors.

• Optionally validate rollback immediately post-deployment to prepare a Quick Deploy.

Profile Packaging

• Avoid special handling by default, except excluding IP Ranges and environment-specific settings.

• EZ Commits can exclude User Permissions (no change = no deployment).

• The "ignore missing visibility settings" is a last-resort workaround that can desync branch and org. Standard fields are unsupported.

Vlocity, as of June 1, 2020, is now a Salesforce company. Vlocity is a set of applications built solely on the Salesforce platform and caters to a number of industries including healthcare, energy, government, entertainment, and insurance. Vlocity is popular among many of our healthcare clients.

For best tracking and visibility, it’s recommended to set a metadata folder path for a repository. This can be completed through the use of the branch settings column in the Repository details. This will enable the metadata to be placed in the specified directory rather than the root directory. This should be completed before any baseline and commits as part of your VC Repo’s registration.

Branching baseline can also be used for periodical metadata backups into a separate backup repository, which can be used to track unplanned manual changes in the orgs.

Branching Baseline is one of the first steps in seeding the master branch. ARM has the ability to populate the Vlocity specific metadata into the master branch using Branching Baseline methodology. These are key metadata items that are extracted as part of the Baseline process for Vlocity. Branching Baseline has the ability to seed master branches for Salesforce-specific Metadata and Vlocity-specific metadata.

• Attachment

• AttributeAssignmentRule

• AttributeCategory

• CalculationMatrix

• CalculationMatrixVersion

• CalculationProcedure

• CalculationProcedureVersion

• Catalog

• ContextAction

• ContextDimension

• ContextScope

• ContractType

• DataRaptor

• Document

• DocumentClause

• DocumentTemplate

• EntityFilter

• FlexCard

• IntegrationProcedure

• InterfaceImplementation

• ItemImplementation

• ManualQueue

• ObjectClass

• ObjectContextRule

• ObjectLayout

• OmniScript

• OrchestrationDependencyDefinition

• OrchestrationItemDefinition

• OrchestrationPlanDefinition

• Pricebook2

• PriceList

• PricingPlan

• PricingVariable

• Product2

• Promotion

• QueryBuilder

• Rule

• StoryObjectConfiguration

• System

• TimePlan

• TimePolicy

• UIFacet

• UISection

• VlocityAction

• VlocityAttachment

• VlocityCard

• VlocityFunction

• VlocityPicklist

• VlocitySearchWidgetSetup

• VlocityStateModel

• VlocityUILayout

• VlocityUITemplate

• VqMachine

• VqResource

Seeding a master repository within ARM is possible for both Salesforce and Vlocity metadata as displayed below:

Upon successfully executing the Branching Baseline by selecting Salesforce and Vlocity for the retrieval type all metadata is placed into the master repository. The Salesforce metadata should be placed in the src directory within the master repository. Additionally, a vlocity.yaml file is created as part of the baseline process. Here is an example of a vlocity.yaml file:

Project path: ./autorabit_alldefault_vlocity_buildmanifest

• Attachment

• AttributeAssignmentRule

• AttributeCategory

• CalculationMatrix

• CalculationMatrixVersion

• CalculationProcedure

• CalculationProcedureVersion

• Catalog

• ContextAction

• ContextDimension

• ContextScope

• ContractType

• DataRaptor

• Document

• DocumentClause

• DocumentTemplate

• EntityFilter

• FlexCard

• IntegrationProcedure

• InterfaceImplementation

• ItemImplementation

• ManualQueue

• ObjectClass

• ObjectContextRule

• ObjectLayout

• OmniScript

• OrchestrationDependencyDefinition

• OrchestrationItemDefinition

• OrchestrationPlanDefinition

• Pricebook2

• PriceList

• PricingPlan

• PricingVariable

• Product2

• Promotion

• QueryBuilder

• Rule

• StoryObjectConfiguration

• System

• TimePlan

• TimePolicy

• UIFacet

• UISection

• VlocityAction

• VlocityAttachment

• VlocityCard

• VlocityFunction

• VlocityPicklist

• VlocitySearchWidgetSetup

• VlocityStateModel

• VlocityUILayout

• VlocityUITemplate

• VqMachine

• VqResource maxDepth: -1 autoUpdateSettings: true separateMatrixVersions: true

In addition to the vlocity.yaml file, the Vlocity metadata is retrieved and placed into the autorabit_alldefault_vlocity_build folder.

When and Why would you need to Whitelist the AutoRABIT IP Address?

IP whitelisting adheres to the Zero Trust model's principle of 'deny all and permit some.' So by default, all unknown entities are denied access to network resources. Because the Customer network by default blocks all traffic, AutoRABIT is unable to access the services on GIT in order to proceed with Salesforce release management.

Application whitelists help in the protection of your system against malware, spam, ransomware, and other threats. Only approved apps can run thanks to application whitelists. Anything that is not whitelisted is deemed unsafe and is blocked.

To facilitate the connectivity of AutoRABIT with your VCS, you need to whitelist the specific IP address allocated to your AutoRABIT instance.

When a customer instance is behind a firewall, one of the methods for configuring connectivity is required. You can either whitelist AutoRABIT instance IPs in your Git network or set up the required VPN Tunnel. Any of these connections can be assisted by AutoRABIT.

Overview

This guide outlines the steps to include network settings during a commit or deployment in AutoRABIT. Following these steps ensures that network access configurations are properly managed and deployed.

Steps to Include Network Settings

1. Metadata Retrieval in EZ-Commit / Deployment

   • During the metadata retrieval stage of an EZ-Commit or Deployment job, ensure the security metadata is included under the settings section.

   • This step ensures that network-related configurations, including IP ranges and login IPs, are captured for commit or deployment.

2. Compare Changes Stage

   • In the Compare Changes stage, review all Network Access changes included in the commit. This is particularly important for existing commits (ex commits).

   • Use this stage to validate that all required network settings have been accurately captured.

Important Note: For secure and efficient deployments, it is recommended to grant IP access based on the deployment profile. This ensures that only the necessary IP ranges are permitted, maintaining both compliance and security standards.

There is no “one size fits all” solution when it comes to branching strategy. This page can only provide general best practices, which need to be adjusted based on specific requirements of the given project (environment landscape and other SDLC details).

Source of Truth

The GIT repository is the sole Source of Truth for the project. Once established, changes can only go from GIT to Salesforce, with the CI Jobs being the only point of entry. Manual changes in the integrated environments, deployments from multiple branches, or other sources (ChangeSet, Workbench, etc.) will get the environment out of sync with the branch, defeating the purpose of version control.

The default main branch in every GIT repository is master and all other branches should be created from it.

Branching and Merging: What's the Difference?

A branch allows you to create a copy (or snapshot) of the repository that you can modify in parallel without altering the main set. You can continue to commit new changes to the branch as you work, while others commit to the trunk or master without the changes affecting each other.

Once you’re comfortable with the experimental code, you will want to make it part of the trunk or master again. This is where merging comes in. Since the version control system has recorded every change so far, it knows how each file has been altered. By merging the branch with the trunk or master (or even another branch), your version control tool will attempt to seamlessly merge each file and line of code automatically. Once a branch is merged it then updates the trunk or master with the latest files.

Branching Baseline

The first step of establishing a CI/CD Pipeline is seeding the repository using the Branching Baseline feature of AutoRABIT. It’s a single commit into the master branch, containing all metadata from Production org.

That baseline revision should be then used as a baseline for all CI Jobs (the only delta after the baseline should be considered for deployments). The Branching Baseline should only be done once in the repository, as for the CI/CD to work correctly, the changes need to be introduced selectively by the developers.

Once the master branch is baselined, all remaining branches can be created.

Branching baseline can also be used for periodical metadata backups into a separate backup repository, which can be used to track unplanned manual changes in the orgs.

Development

Each Sandbox used for development should have a dedicated dev branch. Additional ephemeral branches, usually referred to as feature branches, can be created off of dev and deleted once merged.

For review and approval purposes, the feature branches should be merged to dev using Pull Requests. Every GIT hosting offers its own proprietary API for Pull Requests (GitHub and Bitbucket are currently supported in AutoRABIT, with Azure DevOps to be released soon).

A dedicated CI Job can be created for Pull Request validations, to assist reviewers with Sandbox validation of the code being changed in the Pull Request, as well as running PMD if any Apex changes are present.

The only CI Jobs linked with dev branches would be the Pull Request validation and an on-commit deployment to the Pull Request validation Sandbox, to ensure it’s in sync with the upstream branch.

Once the code in dev, is ready to be moved to QA, the branch should be merged into an integration branch.

Back-Sync

It’s imperative that all dev branches continuously pull the integrated code from integration branch, to get changes introduced from other dev branches. The cadence of these downstream merges depends on the release timelines, but in most cases, it can and should be done as often as new work is being committed.

The integrated code merged down to dev should then be deployed to the linked development Sandbox, either using a CI Job (requires elevated access to modify baseline revision) or Selective Deployment (from a revision range or a single revision).

Integration and Testing

Starting from the integration branch, the flow becomes linear all the way to Production (master), with the driving factor being progression through the testing phases of the project. Each branch has a single CI Job listening to a webhook from GIT, triggering incremental deployments to its test environments (e.g. int > QA > UAT).

Once the testing phase is complete and the changes are signed off on, the branch will be merged to the next one in the flow, triggering a deployment, followed by another phase of testing.

Release

The last stage of the CI/CD Pipeline is staging and release to Production. The staging phase is important, as all deployments until this point were incremental, meaning that components that will build up the Production deployment package were being deployed independently; in some scenarios, new issues could come up in Production only because of the components being deployed in a single package.

A dedicated stage branch is a good practice, as it allows for easier tracking of code signed-off for release to Production. It also allows for a consistent CI Job configuration across the pipeline (on-commit deployment upon merge to staging, same as with all lower testing environments.

The code can be promoted to master in parallel with final regression testing in Staging - the sooner the validation against the Production environment happens, the better, as there is always a risk of environment-specific issues happening in Production, which were not observed earlier deployments.

Both Staging and Production CI Jobs should be configured as non-incremental and on-commit with rollback option enabled; Stage should deploy, while Production only validate, both running Unit Tests (either RunLocalTests or RunTestsBasedOnChanges).

Hotfix

A hotfix process, also known as an emergency change request, occurs when there is a critical issue found in Production, which needs to be fixed sooner than the nearest planned release.

Such change is exactly the same as other changes (committed to a feature branch, merged into dev branch, and optionally to integration branch), but skips most testing phases.

Once hotfix revision is introduced to the dev/integration branch, it can be promoted directly to the stage/master branch for final validation and deployment to Production. This can be achieved either by “Single Revision”, “Commit Label” or “Release Label” merge types in AutoRABIT.

Org Synchronization feature in AutoRABIT does a component-level metadata comparison between two Salesforce orgs. With this feature, you can either add or delete an object or metadata member, making sure that both the orgs are in sync. However, you won't be able to see the content level differences.

For content-related comparison between two Salesforce Orgs, please refer to the following steps:

1. Go to Menu > Deployment > New Deployment

2. Give a Label name.

3. Select Deployment From as Salesforce Org.

4. Select your Source & Destination Org.

5. Click on Retrieve Metadata.

6. Select the component for which you want to view the content level differences and click on Compare Metadata & Deploy.

7. In the next screen, AutoRABIT retrieves the components from both the orgs and generates a difference if it exists and displays the same.

Translation feature can help you translate almost everything in your organization ranging from Salesforce custom objects, fields, labels, etc. This provides users with different languages to interact with Salesforce.

A. Commit and deploy 'Custom Object' translations with ARM

In order to translate custom objects for a variety of languages, you need to commit the following components.

1. Select the CustomObject metadata type and select the specific custom objects that you want to move the translation.

1. Select the CustomObjectTranslation metadata type and select the translations associated with the custom object.

Point to Note:

• The translation will not take place and nothing will be retrieved if you merely use the CustomObjectTranslation metadata type and leave out the Custom Object.

• The translation should be activated for the custom object in the destination org.

B. Commit and deploy 'Custom Field' Translations with ARM

To commit and deploy custom field translations with ARM, you need to commit the following components.

1. Select the CustomField metadata type and select the specific custom fields that you want to move the translation.

1. Select the metadata type CustomObjectTranslation and select the members associated with the custom object.

Troubleshooting:

In some circumstances, the CustomObjectTranslation might just have the opening and closing xml tags. In this situation, we advise you to do a commit while selecting the Review Artifacts option, allowing you to inspect the contents of the files before committing them.

C. Commit and Deploy 'Custom Label' Translations with ARM

Translations for custom labels determine what text to display for the label’s value when a user’s default language is the translation language.

To commit or deploy custom label translations with ARM, you need to commit the following components.

1. Select the name of the custom label you want to translate available under the CustomLabel metadata type.

1. Look for the Translation metadata type and select the language from the list.

D. Commit and Deploy 'Field Set' Translations with ARM

A field set is a group of different fields. For example, a field set that contains fields describing a user's first name, last name, occupation, etc.

In order to commit and deploy field set translations with ARM, you need to commit the following components.

1. Select the FieldSet metadata type and select the specific field set(s) that you want to move the translation.

1. Select the metadata type Translations and select the language you want the translations to be moved. This deploys the field sets along with the translations for the language selected.

E. Commit and Deploy 'Standard Value Set' Translations with ARM

In order to commit and deploy standard value set translations with ARM, you need to commit the following components.

1. Select the StandardValueSet metadata type and select the specific standard value sets that you want to move the translation.

2. Select the StandardValuesetTranslation metadata type and select the respective metadata members from the list.

3. Select the metadata type Translations and select the language you want the translations to be moved. This deploys the standard value sets along with the translations for the language selected.

F. Commit and Deploy 'Global Value Set' Translations with ARM

In order to commit and deploy global value set translations with ARM, you need to commit the following components.

1. Select the GlobalValueSet metadata type and select the specific global value sets that you want to move the translation.

2. Select the GlobalValuesetTranslation metadata type and select the global value set translations metadata members from the list.

3. Select the metadata type Translations and select the language you want the translations to be moved. This deploys the global value sets along with the translations for the language selected to the Version Control branch.

What is a Deployment?

The Deployment process allows you to easily and safely transfer new developments from your sandbox instance to a production instance. Using the deployment process, you will be able to transfer validation rules, custom objects, new fields, Apex codes, and many other components from your development environment to a live production environment.

Different Deployment Methods

Once you are done with your development, you need to migrate your code from your development organization to the organization where business users can use your code. There are different methods of deploying the changes to a target/production org in AutoRABIT, such as deployment via Salesforce Org/Version Control, Revision Range, Release Label, etc.

Deployment via Revision Range

Deployment via revision range is all about deploying the codes based on a range of committed revisions. Multiple revisions can be a part of this deployment based on the from and to revision selection.

For example, to deploy the below-mentioned commit revisions to your target org;

Choose the From Revision Date as a1022af and the To Date as d86165a while you're carrying out the deployment via revision range.

Changes on Custom Object

Let’s take a look at the changes when, for instance, a custom object is selected and deployed using the Revision Range operation:

1. The custom object is a part of the initial revision but gets deleted in the revision ranges selection.

   • The custom object becomes part of the Destructive Items list.

   • Custom object-related fields become part of the Destructive Items list.

2. The custom object is a part of the revision ranges selection

   • The custom object is added in one of the revisions and deleted in other revisions. In this scenario, the custom object is not considered a Destructive Items or in the Added/Modified list.

   • The custom object is modified in between the revision ranges. In this scenario, the custom objects will be treated as a Modified Items list.

3. The custom object is not a part of the initial revision, but is newly added in the revision ranges selection

   • The custom object will be treated as an Added Item list and will get deployed to the target org.

Changes on Profile

The profile is a collection of settings and permissions that define how a user access records. Let’s take a look at the changes when, for instance, a profile object is selected and deployed using the Revision Range operation:

1. The profile is a part of the revision ranges selection.

   • The recent settings and the permissions changes allocated to the Profiles for the revision ranges are deployed.

2. The profile is a part of the initial revision but gets deleted in the revision ranges selection.

   • The profile becomes part of the Destructive Items list.

   • The profile-related settings and permissions become part of the Destructive Items list too.

Changes on Apex Class

Looking at the changes when, for instance, an Apex class is selected and deployed using the Revision Range operation:

1. The apex class is a part of the initial revision, but is deleted in the revision ranges selection

   • The apex class becomes part of the Destructive Items list.

   • The apex class-related fields become part of the Destructive Items list.

2. The Apex class is a part of the revision ranges selection

   • The apex class is added in one of the revisions and deleted in other revisions. In this scenario, the apex class is not considered a Destructive Items or Added/Modified list.

   • The apex class is modified in between the revision ranges. In this scenario, the Apex class is treated as a Modified Items list.

3. The Apex class is not a part of the initial revision, but is newly added in the revision ranges selection.

   • The Apex class will be treated as an Added Item list and deployed to the target org.

Deployment via Release Labels

This deploys the changes that are available in your release labels. A release label is simply a group of single revisions combined.

Changes on Custom Object

Let’s take a look at the changes when, for instance, a custom object is selected and deployed using the Release Label operation:

1. The custom object is a part of the release label:

   • The custom object, along with its related fields, will be part of the deployment.

2. The custom object is not part of the release label:

   • The custom object will not be deployed to the target org.

Changes on Profile

The profile is a collection of settings and permissions that define how a user access records. Let’s take a look at the changes when, for instance, a profile object is selected and deployed using the Release Label operation:

1. The profile is part of the release label:

   • The entire settings and the permissions allocated to the Profiles will be deployed.

2. The profile is not part of the Release Label:

   • The profile and its related settings and permissions will not be deployed.

Changes on Apex Class

Let’s take a look at the changes when, for instance, an Apex class is selected and deployed using the Release Label:

1. The Apex class is a part of the release label:

   • The Apex class along with its related fields will be part of the deployment.

2. The Apex class is not part of the release label:

   • The Apex class will not get deployed to the target org.

Delta Metadata Generation for Release Label Deployments

NOTE: For Release Label Deployments, ARM generates delta metadata only for the components listed below.

For DX Repo Release Labels, the supported components are:

• autoResponseRules

• bot

• escalationRules

• matchingRule

• labels

• object

• sharingRules

• workflow

For Non-DX Repo Release Labels, the supported components are:

• autoResponseRules

• bot

• matchingRule

• labels

• object

• translation

• sharingRules

• workflow

At this time, delta generation is limited to these components, and no other metadata is supported when utilizing Release Label Deployments.

We're exploring a solution to support Release Label delta components, and it’s currently being considered in our product backlog. While we don’t have a confirmed timeline yet, we’ll keep you informed as more information becomes available.

Release Label Deployment Behavior

Note: If you skip some in-between revisions while creating a Release Label and include a later revision, AutoRABIT will still pick up changes from the skipped revisions in the Release Label Deployments, but only if those changes are related to the same metadata component as the selected revisions.

For example, if we create a Release Label by including Commits 1, 2, and 4 as shown in the screenshot above, and then deploy using that Release Label to a target Salesforce org, the deployment will still include the changes from Commit 3, even though it was skipped in the Release Label.

Salesforce API Version Mismatch for the CI Build and the Custom Deployment.

To troubleshoot, run the following command to see the default API version for the SFDX:

sfdx config:get apiVersion --json

Next, run the following command to change the SFDX API version. For example, changing the API Version to 51.0:

sfdx config:set apiVersion=51.0 --global

Finally, run the command to see the configured API version:

sfdx config:get apiVersion --json

Complete the following steps before starting a commit operation in AutoRABIT:

1. Register Your Version Control Repository

   • Only an administrator can perform this step.

   • Register your version control system (e.g., Git, SVN, or TFS) in AutoRABIT.

2. Register Your Salesforce Organization

   • Connect AutoRABIT to your Salesforce Org using OAuth or username/password authentication.

   • This step requires admin-level access.

3. Set Up a Branch

   • Create a feature branch to isolate changes instead of editing the main code base directly.

   • This operation must be performed by an administrator.

4. Map Users to Version Control and Salesforce Orgs

   • In the My Profile section, map users to the registered Salesforce Orgs and version control repositories.

   • Assign necessary permissions to allow project creation in AutoRABIT.

What is a Flow?

In Salesforce, a flow is an application that automates complex business processes. It collects data and performs actions with it—helping users save time, avoid errors, and streamline tasks. Flows are an essential tool for automating manual processes and ensuring consistency across the platform.

Different Categories of Flows

Salesforce flows fall into five main categories:

1. Screen Flows – Include user interface elements; require user input. They can be launched via actions or embedded in Lightning pages.

2. Schedule-Triggered Flows – Run in the background at specified intervals for each record in a batch.

3. Autolaunched Flows – Perform tasks without user interaction. These can be triggered from Process Builder, Apex, schedules, record changes, or platform events.

4. Record-Triggered Flows – Automatically triggered in the background when a record is created, updated, or deleted.

5. Platform Event-Triggered Flows – Triggered when a platform event message is received.

When and Why Should I Use a Flow?

• Flows can create, edit, and delete records passed into them—even unrelated records.

• Flows can be scheduled to run at set intervals for collections of records.

• Unlike workflow rules, which can only update related records, flows offer more flexibility and broader actions.

• Compared to Process Builder, flows can also delete records and provide UI elements.

Flows vs. Process Builder vs. Workflows vs. Apex

Activate or Deactivate a Flow

Only one version of a flow can be active at a time. When a new version is activated, any previously active version is deactivated automatically.

Deployment Note: The flow and its latest definition must be included in the deployment package to deactivate it in Salesforce.

What is a Flow Interview in Salesforce?

A flow interview is a running instance of a flow. For example, a flow may serve as a call script for customer support. As the user interacts with it, Salesforce captures the input and executes the defined actions. Whether accessed via a link, button, or tab, a flow interview represents a single execution of that flow logic.