> For the complete documentation index, see [llms.txt](https://docs.flosum.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flosum.com/devops/code/branch-actions/deploying-a-branch.md). # Deploying a Branch Deployment pushes your branch’s metadata components into a target Salesforce org. It actually applies changes, making it the final step in moving code/config into Salesforce environments. {% hint style="warning" %} #### Written for the Old UI This article was written for the old UI. The instructions are still usable, but the screenshots are outdated. In some cases, items referenced in the instructions have moved or changed. If you cannot find an item, see the [Where Did It Go](/devops/new-ui-ux-transition/where-did-it-go.md) article. {% endhint %} ## ![](https://1800549522-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRpUu5iMlzMFAudyBvMOl%2Fuploads%2FG5ZbxX918xOHwbAwAJ4n%2FSummary2-Small-Icon.svg?alt=media\&token=da26a67f-ff7f-47b3-8669-06be960dc2d7) Overview Deploying a branch lets you migrate metadata components from a Cloud DevOps branch to a Salesforce Organization that is connected to DevOps. The deployment process ensures that: * Selected branch components are applied to the target org * Optional destructive changes can remove metadata no longer needed * Apex tests and post-deployment steps run for compliance and stability By running a deployment after validation, you can confidently promote changes to higher environments such as UAT and Production. {% hint style="info" %} #### Validation Recommended Before deploying, conduct a validation job using the branch, components, and organization intended for deployment. Ensure the validation is successful before proceeding. For detailed validation instructions, refer to the following article. * [Using Branch Validate](/devops/code/branch-actions/using-branch-validate.md) {% endhint %} {% hint style="info" %} #### Best Practices * Always validate before deploying into UAT or Production. * Use **Pre** and **Post** destructive changes carefully; confirm items are safe to delete. * In production environments, always select **Run all tests** or **Run local tests**. In lower environments, you can select **Do not run tests** to enable faster deployments. * Use Profile/Permission Set scoping to avoid unnecessary overwrites. * Review logs carefully after deployment to confirm success. * Leverage **Rollback** immediately if unexpected issues occur. {% endhint %} ## Run Branch Deployment Job {% stepper %} {% step %} ### Select a Branch and Start Deployment 1. Click **Code** from the left sidebar menu. 2. Select a branch from the list.

3. Click **Deploy**.

{% endstep %} {% step %} ### Select Components and Organization 1. Click **Add** for each branch component to include in the deployment. 2. (Optional) Click **Add all** to add all components to the deployment. 3. Click **Next**.

4. Click **Select** to choose the Salesforce organization for deployment. 5. Click **Next**.

{% endstep %} {% step %} ### Select Destructive Changes Components can be marked for **Pre** (delete before deploy) or **Post** (delete after deploy). {% hint style="info" %} By default, all pre- and post-destructive changes are added. {% endhint %} 1. (Optional) To remove a destructive change from the deployment, click **Added** to unselect the component. 2. Click **Next**.

{% endstep %} {% step %} ### Configure and Run Deployment 1. Click the **Run tests** dropdown menu to choose the level of Apex testing to perform. See the table below for a description of each.

Test Level	Description
Default	Runs only the tests included in the package.
Do not run tests	Skips all Apex tests (allowed only in non-production orgs).
Run local tests	Executes all tests in the org except those from installed managed packages.
Run all tests	Runs every test in the org, including managed package tests.
Run relevant tests	Runs only the tests relevant to the selected components and their dependencies. This option uses Salesforce’s RunRelevantTests feature to automatically determine which tests to run. For more details, see Salesforce Help.
Run specified tests	Lets you define individual test classes or methods to run.

2. Click the deployment settings toggles to enable the settings. See the following table for an explanation of each setting.

Setting	Description
Deploy profile settings only for selected components	Only validate Profile Settings for the components you chose to include in this validation job.
Deploy permission set settings only for selected components	Only validate Permission Set Settings for the components you chose to include in this validation job.
Run post deploy Apex code	Executes defined Apex scripts after deployment completes. When enabled, a text box is available for entering scripts.
Ignore warnings on deployment	Allows deployment to continue even with warnings.
Vlocity LWC Activation	When enabled, Vlocity Lightning Web Components are automatically activated, compiled, and made runnable during deployment.

3. Click **Run** to start the Deployment job.

4. After starting the Deployment job, it will be displayed on the **Activities** tab.

{% endstep %} {% step %} ### In Progress Deployment During a **Deploy** job that is **In Progress**, you can monitor its status and cancel it if needed. 1. Click the **In Progress** Deploy job.

**Refresh Logs** 1. Click **Refresh** to refresh the log view with the current log.

**Abort Deployment** 1. Click **Abort**.

2. Click **Abort** in the **Abort Deploy** confirmation dialog.

3. The Deploy job has stopped, and no further actions will be performed on the Salesforce Organization.

{% endstep %} {% endstepper %} ## Deployment Results {% stepper %} {% step %} ### View Results 1. Click the **Activities** tab. 2. Check that the **Deploy** job status is **Completed**. {% hint style="info" %} If an error occurs during the Deploy job, its status will change to **Exception**. Review the Deploy job log to identify the errors. {% endhint %}

Job Status	Description
Queued	Job is created and waiting to run.
In Progress	Job is running.
Completed	Job completed successfully.
Exception	Job completed with errors.

3. Click the **Deploy** job.

4. The **Deploy** results page lists job information and a detailed log.

{% endstep %} {% step %} ### Review Log (No Errors) In the Deploy job log, details include: * Presence of Destructive Changes objects. * Count and list of deployed components. * Type and results of the Apex test run. * Deployment steps completed.

{% endstep %} {% step %} ### Review Log (With Errors) When a Deploy job encounters an error, examine the logs to identify the cause. Focus on entries marked with **\[error]**. The screenshots below show a Deploy job run in which a Salesforce org is missing multiple components required by the branch.

{% endstep %} {% step %} ### Rollback Deployment On the deployment results page, if a backup was created, you will see a **Rollback** button. Clicking Rollback restores the organization to its state before the deployment, using the backup snapshot. For detailed instructions on this process, refer to the following article. * [Rolling Back a Deployment](/devops/code/branch-actions/rolling-back-a-deployment.md) {% endstep %} {% endstepper %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.flosum.com/devops/code/branch-actions/deploying-a-branch.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.