Home / devops / devops-center-advanced
devops-center-advanced
Use DevOps Center for work item tracking, org-based release pipelines, and merging into existing SFDX workflows. NOT for first-time setup — use admin/devops-process-documentation.
Open the skill folder on GitHub
DevOps Center Advanced Workflows
DevOps Center gives a click path over a source-tracked pipeline. Its value is a single property: the org's state is derivable from one artifact — the work item and its branch. Every practice in this skill exists to protect that property, and every failure mode in it is a case where a second writer broke it.
This skill assumes the pipeline already exists. It covers making DevOps Center coexist with a CLI workflow, surviving an emergency without diverging the repository from production, resolving the metadata types that conflict badly, and deciding whether to move from the managed package to the native next-generation product.
Establish Which Product First
Two things answer to "DevOps Center" and Salesforce documents them separately. Nearly every wasted hour in this domain starts with guidance written for the other one.
| DevOps Center (Managed Package) | Next Generation DevOps Center | |
|---|---|---|
| Delivery | Installed and configured as a managed-package app | Native platform capability; no package install |
| Source control | GitHub | GitHub, Bitbucket (beta) |
| Change tracking | In-app | DX Inspector, surfaced inside the sandbox / scratch org / Developer Edition org |
| Governance | Users | Policies covering coding agents as well as users |
| Availability | See the managed-package setup docs | Professional Edition with API access or higher; Lightning Experience; excluded in Government Cloud Plus and the EU Operating Zone |
The strongest tell in any document: if setup begins with installing a package, it is the managed-package product.
Recommended Workflow
- Establish the product and its constraints. Managed package or
next-generation, and — for next-generation — confirm the edition and region are eligible before any migration analysis.
- Make the work item the unit of promotion for everyone. Admins reach it
through the UI (or DX Inspector); developers check out the work item's branch and keep the CLI, local tests, and their editor. Enforce the negative rule: no branch that is not a work-item branch merges into a pipeline branch.
- Front-load validation. Run
sf project deploy validate --test-level ...against a test stage on every work item so the expensive test run happens early, off the shared org's critical path.
- Promote to production as validate-then-quick.
sf project deploy validatewith an explicit test level, then
sf project deploy quick --job-id <id>. Set--test-levelexplicitly on every command in every environment. - Write the bypass runbook before you need it. Pre-state capture, validate,
quick-deploy, then a mandatory cascade of the change down the pipeline. Count bypasses monthly.
- Serialize the metadata types that conflict badly. Treat "who edits which
flow this sprint" as a work-item assignment constraint; retrieve-merge-commit permission sets and profiles rather than committing deltas.
- Prune on a stated cadence. Merged branches and closed work items, with a
retention window written down rather than left to accretion.
Key Considerations
A commit outside the work-item branch is invisible to the promotion. The promotion moves the work item's branch. A change merged directly into a pipeline branch is real in git and absent from the promotion record, so the environments diverge while the pipeline reports success.
Permission sets and profiles deploy as a full replace. Anything in the target org that is not in the deployed XML is removed, silently. The work-item model makes this easier to hit because the natural commit is a delta. See devops/permission-set-deployment-ordering.
Flow XML conflicts are not textually resolvable. A flow version is one XML document with canvas coordinates embedded. A syntactically valid hand-merge can point a connector at the wrong element and deploy without error. Accept one side wholesale and re-apply the other change in Flow Builder.
Promotion runs tests in the target org, and target orgs are shared. On a shared UAT org, the constraint is org capacity, not pipeline throughput — which is why front-loading validation matters more than it looks.
An un-reconciled bypass is a scheduled future incident. Applied to production only, it is reverted by the next normal promotion from a lower environment, and nothing warns you because the promotion did exactly what its branch said.
--test-level omitted means the org's default applies. The same command then behaves differently against different orgs, which is precisely what a pipeline exists to eliminate.
The sf project deploy pipeline commands ship in a separate plugin, and are beta. They are not in the base CLI: install sf plugins install @salesforce/plugin-devops-center first, or every one of them is "command not found" on a clean runner. start, validate, quick, report, and resume deploy from a branch into a pipeline stage's org — the supported way to put promotion behind CI. Because both the plugin and the commands are beta, pin the plugin version in the CI image and pilot before depending on it.
Coding agents commit at machine speed. The governance layer in next-generation DevOps Center covers agents as well as users; set the policy before granting write access, and keep the promotion gate as the point where a human looks at the diff.
Worked Examples (see references/examples.md)
- Admins in the UI, developers in the CLI, one pipeline — the shape that works
and the rule that makes it hold.
- A bypass runbook written before you need it — including the reconciliation
step that gets skipped.
- Two admins, one flow, one merge conflict — resolving it without corrupting
the flow.
- Wrong vs right: testing on the promotion — validate-then-quick, and the
beta pipeline CLI commands.
- Deciding whether to move to next-generation DevOps Center — blockers, not
version numbers.
Common Gotchas (see references/gotchas.md)
- Two products answer to the same name — establish which before acting on
any guidance.
- A non-work-item commit is invisible to the promotion.
- Flow conflicts corrupt silently when hand-merged.
- Permission set deploys are a full replace.
- An un-reconciled bypass is reverted by the next normal promotion.
- The pipeline CLI commands and Bitbucket support are beta.
Top LLM Anti-Patterns (full list in references/llm-anti-patterns.md)
- Answering about the managed package when the org is on next-generation.
- Recommending parallel git and DevOps Center workflows as a feature.
- Improvising an emergency bypass with no reconciliation step.
- Omitting
--test-level. - Proposing a manual merge for a flow XML conflict.
Related
devops/permission-set-deployment-orderingdevops/flow-deployment-activation-orderingdevops/salesforce-cli-automationdevops/deployment-error-diagnosisdevops/metadata-api-retrieve-deployadmin/devops-process-documentation— first-time setup, out of scope here.
Official Sources Used
- Next Generation DevOps Center — https://help.salesforce.com/s/articleView?id=platform.next_generation_devops_center.htm&type=5
- Considerations to Set Up Next Generation DevOps Center — https://help.salesforce.com/s/articleView?id=platform.next_gen_devops_center_setup_considerations.htm&type=5
- Install and Configure DevOps Center (Managed Package) — https://help.salesforce.com/s/articleView?id=platform.devops_center_setup.htm&type=5
- Promote Work Items Through Your Pipeline — https://help.salesforce.com/s/articleView?id=platform.devops_center_work_items_promote.htm&type=5
- Salesforce CLI Command Reference,
sf project deploy— https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_project_commands_unified.htm
The full annotated list is in references/well-architected.md.