DevOps Center
DevOps Center is Salesforce's first-party release management tool, generally available since December 2022.
Definition
DevOps Center is Salesforce's first-party release management tool, generally available since December 2022. It replaces Change Sets with a Git-backed workflow: developers and admins work in sandboxes or scratch orgs, the platform tracks their changes as work items, and DevOps Center promotes those changes through a pipeline of environments (Dev to UAT to Production) by writing to a GitHub repository. The tool is free for any org and is Salesforce's recommended replacement for sandbox-to-sandbox Change Sets.
DevOps Center bridges the gap between Change Sets (limited but easy) and full Salesforce DX with the CLI (powerful but expects CLI fluency). Admins and low-code builders use it through the Salesforce UI, while developers can still use the CLI and Git directly because everything lives in the same GitHub repo. The pipeline is configurable: define your environments, the order they connect, and what triggers promotion.
What DevOps Center adds to Salesforce release management
Work items as the unit of change
DevOps Center introduces Work Items: named bundles of metadata changes tracked through the pipeline. A developer creates a Work Item in DevOps Center, deploys it to their dev sandbox, makes the changes there, then commits the diff back through the UI. The Work Item is now versioned in Git with the commit, and DevOps Center can promote it to the next environment in the pipeline.
The pipeline of environments
DevOps Center supports a configurable pipeline of environments: typically Dev, then Integration, then UAT, then Staging, then Production. You define each environment as either a sandbox or a production org, and the order they connect. Promoting a Work Item from one environment to the next merges its branch in Git and deploys to the target org. The flow is more like GitFlow or trunk-based release than Change Set ad-hoc promotion.
GitHub integration and what gets stored
The repository is required. DevOps Center supports GitHub (Cloud or Enterprise) as the source-of-truth. Each Work Item becomes a branch; promotion is a merge to the next environment's tracking branch. The repo holds force-app source, sfdx-project.json, and DevOps Center's own state files. Treat the repo as you would a regular software repo: pull requests, branch protection, code review where appropriate.
Bundles and the deployment unit
Work Items can be bundled for coordinated release: a Bundle is a set of Work Items that should be promoted together. This solves the dependency problem in Change Sets where two related changes had to ship in one set or risk one half breaking. Bundles are a soft container: you can add or remove Work Items until the bundle is promoted.
Permissions and the DevOps Center license
DevOps Center is free for any org but requires the DevOps Center license to be assigned to users (Setup, then Users, then Permission Set Licenses, then DevOps Center). Developers and admins who manage releases need the full license; others might only need to view release status. The license is included with the platform; you do not pay extra.
DevOps Center versus Change Sets versus Salesforce DX
Change Sets: easy, but unversioned, brittle, related-orgs-only. Salesforce DX with the CLI: powerful, version-controlled, but requires CLI fluency. DevOps Center: UI-driven like Change Sets, Git-backed like Salesforce DX, free of charge. For teams currently on Change Sets, DevOps Center is the obvious next step. For teams already on Salesforce DX with custom CI pipelines, DevOps Center may feel constraining; it depends on whether you want a managed flow or full control.
What DevOps Center cannot do yet
DevOps Center handles most common cases but has gaps: it does not yet support all metadata types (some Industries-specific metadata is excluded); merge conflict resolution is partially manual; data deployment (records, not just metadata) is not handled; and advanced policy enforcement (approvals, compliance gates) is lighter than Copado or Gearset. Watch the release notes for catch-up announcements.
How to set up DevOps Center for a Salesforce org
DevOps Center setup involves enabling the feature, connecting a GitHub repository, defining environments, and assigning user permissions. Plan an hour for the initial configuration; daily use takes minutes.
- Enable DevOps Center
Setup, then DevOps Center, then Enable DevOps Center. Confirm and save. The DevOps Center app appears in the App Launcher.
- Connect a GitHub repository
Open the DevOps Center app. Click Connect to GitHub. Authenticate with a GitHub account that has admin access to the target repo. Pick the repo and the default branch.
- Define the environment pipeline
Add each environment (sandbox or production) to the pipeline. Order them: Dev first, then UAT, then Staging, then Production. Each environment has a tracking branch in the GitHub repo; DevOps Center creates these automatically.
- Assign DevOps Center licenses
Setup, then Users, then Permission Set Licenses, then DevOps Center. Assign the license to developers and release managers. Without it, users cannot create or promote Work Items.
- Create a Work Item
In DevOps Center, click New Work Item. Pick the source environment and describe the change. The platform creates a branch in GitHub and assigns the Work Item to your user.
- Deploy work to the first environment
With the Work Item active, DevOps Center can pull changes from the source sandbox into the branch. Make changes in the sandbox, then commit them through DevOps Center to the branch. Promote the Work Item up the pipeline by clicking Promote.
The unit of change in DevOps Center. Each is a Git branch that promotes through the pipeline.
The configured chain of environments. Defines the promotion path.
A group of Work Items that promote together. Solves the dependency-coordination problem.
The required source-of-truth. Holds all DevOps Center state and metadata.
- DevOps Center requires GitHub specifically. GitLab, Bitbucket, and Azure DevOps are not supported yet. Plan accordingly if your team standardizes elsewhere.
- Some metadata types are unsupported. Industries-specific configurations, certain managed-package metadata, and some platform features cannot be deployed through DevOps Center yet.
- Pipeline changes are slow to propagate. Reordering environments or adding new ones can take several minutes for the platform to reflect.
- Merge conflicts in GitHub do not auto-resolve. DevOps Center surfaces them but you handle resolution in Git, not in the UI.
Trust & references
Straight from the source - Salesforce's reference material on DevOps Center.
- DevOps Center OverviewSalesforce Help
- Set Up DevOps CenterSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Governor Limit in the context of DevOps Center?
Q2. What is required before deploying DevOps Center-related code to production?
Q3. Where would a developer typically work with DevOps Center?
Discussion
Loading discussion…