Deploy a package from a Salesforce Org

1,000,000 Customers Have Moved to SF CLI. Are You Ready?

Why Does Salesforce Recommend Moving From SFDX to SFCLI? Click here for more info.

Overview

Back up your Salesforce metadata to version control and trigger a deployment to a Salesforce org based on a Start Date. This job can be further customized to run functional test cases from the ARM TAF library or from version control.

Procedure

1. Log in to your ARM account.

2. From the top navigation pane, navigate to Create New > New CI Job.

   
3. Choose the tile: Deploy From Salesforce Org

   
4. Enter a descriptive Job Name.

5. Add a brief Description.

6. (Optional) Choose a Group to organize the job, or click + to create a new group.

7. The configuration page is divided into sections explained below.

Build

Under Build, provide:

1. Source Salesforce Org – The org to retrieve metadata from.

2. Package Type – How ARM gathers metadata:

   • Unpackaged Mode: Retrieves metadata modified since the last ARM cycle (or since Start Date, if set).

   • Unmanaged Packages: Provides editable building blocks installed as application templates.

   • Managed Packages: Used by partners to distribute applications created in a Developer Edition org.

   For more information, see the Salesforce help article.

Additional Options in the Build Section

1. Auto Switch to Bulk Retrieve Service if Job Hits Metadata Governor Limit: Use batch retrieval when a job approaches the 10,000-file or 39-MB limit. Specify Batch Size (up to 10,000).

2. Exclude Installed (Managed) Components and Changes: Skip all managed-package components.

   • Exclude All Manually Created Components: Also skip custom components in managed packages.

3. Incremental Build: Fetch only metadata changed since the previous successful deployment, improving build time.

4. Include Picklist Modifications: Always include picklist fields, even if the “last modified” date is unchanged (source = Salesforce org only).

5. Prepare Destructive Changes: Delete unwanted metadata in the destination org before deployment.

6. Generate Code Coverage Report: Include Apex test-coverage details.

7. Run Static Analysis Report: Identify code-quality issues before production.

   

   • Apex PMD / Checkmarx: Set scan criteria and Priority. If the threshold is not met, the build is marked unstable.

     
   • CodeScan / SonarQube: Choose to scan all metadata or only newly added components, then set a Priority.

     • Run on All Supported Metadata Types: Scan every retrieved component.

     • Run on Newly Added Supported Metadata Types: Scan only newly added components.

       

   For more information on running Static Code Analysis in CI Jobs, see this guide.

8. Additional Profile Packaging Options:

   • Remove Login IP Ranges: Omit IP-range restrictions from profiles.

   • Remove System and User Permissions: Omit profile permissions from deployment.

   • Exclude Metadata Types: Skip metadata you don’t need in the build.

Deploy

Deploy or validate the package in a destination org:

• Deployment Org: Select the destination org.

• Apex Test Level: Choose the test scope:

  

  1. Use Salesforce Defaults – Default Salesforce behavior.

  2. No Test Run – No tests unless deploying to production.

  3. Run Specified Tests – Run only named tests; ARM checks coverage per class (75 % minimum).

  4. Run Local Tests – Run all tests except those from managed packages.

  5. Run All Tests in Org – Run every test, including managed-package tests.

  6. Run Tests Based on Changes – Identify and run relevant test classes; optionally update the default test-class list.

Additional Deployment Options

1. Validate Only: Run validation without deploying.

   • Prevent Deployment: Disable deployment for validation-only jobs.

1. Rollback: Save a backup to allow rollback.

2. Ignore Missing Visibility Settings if Package Contains Profiles or Permission Sets: Deploy profiles/permission sets even if visibility settings differ.

3. Ignore Installed (Managed) Components: Skip managed-package components.

   • Ignore All Manually Created Components: Also skip custom managed-package components.

4. Ignore Warnings: Deploy even if warnings occur.

5. Do Not Include 'Skip Members' During Deployment: Override global skip settings for this deployment.

6. Run Destructive Changes: Choose pre- or post-destructive changes.

7. Apply Search and Substitute Rules: Apply custom find/replace rules during deployment.

8. On Successful Deployment: Trigger post-deployment actions (Skuid pages, CI jobs, environment templates, DataLoader processes, merge processes, Jenkins jobs, parallel processors, or a sequence of activities).

   

   You can sequence multiple post-deployment actions:

   

   

Dependency Analyzer

Analyze metadata dependencies to avoid breaking changes:

Tests

Run functional tests before deployment:

• Version Control: Choose repository, branch, and test type (TAF, Selenium Maven, Selenium Non-Maven).

  
• AccelQ: Enter Project Name, Test Job Name, and parameters.

  
• Provar: Provide repository, branch, test-case root path, and execution path.

  

Callout URL

Configure HTTP callouts to external services. See the Callout URL guide.

Notifications

Send success or failure emails to selected recipients.

Schedule

• Daily – Run every day at the chosen time or interval.

• Weekly – Run on selected day(s) and time.

• No Schedule – Save the job and trigger it manually.

Save

Click Save to store the CI job settings.

If you deploy compiled FlexCard and OmniScript objects, verify both:

1. The destination org is registered via OAuth (not Standard).

2. Local Compilation is enabled in My Account and the correct Access Key is entered.

For credential-usage details across CI job types, see the FAQ.