deploying-metadata
forcedotcom/sf-skills
Salesforce DevOps automation: deploy metadata safely with sf CLI v2, validate first, orchestrate CI/CD.
What is deploying-metadata?
This skill handles Salesforce metadata deployment orchestration using sf CLI v2. Use it when deploying metadata, managing scratch orgs and sandboxes, setting up CI/CD pipelines, or troubleshooting deployment failures. It covers dry-run validation, manifest-based deploys, release sequencing, and failure triage.
- Validate deployments with dry-run before executing real changes
- Deploy metadata via source-dir, manifest, or quick-deploy workflows
- Orchestrate safe release sequencing across objects, permission sets, Apex, and Flows
- Troubleshoot deployment failures and dependency ordering issues
- Guide CI/CD pipeline setup and test-level selection
- Manage scratch orgs, sandboxes, and multi-org deployment strategies
How to install deploying-metadata
npx skills add https://github.com/forcedotcom/sf-skills --skill deploying-metadata- sf CLI v2 installed and authenticated to target org
- sfdx-project.json configured with package directories
- Appropriate org permissions for deployment and validation
How to use deploying-metadata
- 1.Gather required context: target org alias, deployment scope (source-dir/manifest/metadata list), and test level requirements
- 2.Run preflight checks: sf --version, sf org list, sf org display --target-org <alias>
- 3.Execute dry-run validation: sf project deploy start --dry-run --source-dir force-app --target-org <alias> --wait 30 --json
- 4.Review validation results for errors or warnings
- 5.If validation succeeds, deploy with appropriate scope and test level
- 6.Verify deployment: sf project deploy report --job-id <job-id> --target-org <alias> --json
- 7.Confirm tests passed, Flows activated, and permission sets assigned as expected
Use cases
- Validating a metadata change set before production deploy to catch errors early
- Deploying custom objects and fields in correct order to avoid dependency failures
- Setting up a CI/CD pipeline with automated validation and test gates
- Troubleshooting a failed deployment due to missing dependencies or validation rule conflicts
- Quick-deploying validated changes to production after successful dry-run
- Salesforce DevOps engineers
- Release managers orchestrating multi-org deployments
- CI/CD pipeline builders
- Developers troubleshooting deployment failures
- Teams managing scratch org and sandbox lifecycles
deploying-metadata FAQ
Always use --dry-run first to validate metadata and catch errors before real deployment. Only deploy after successful validation.
Deploy in this order: 1) Custom objects/fields, 2) Permission sets, 3) Apex, 4) Flows as Draft, 5) Flow activation. This prevents dependency and FLS failures.
Use --manifest with a package.xml file for targeted deploys, or --metadata to specify individual components. This reduces risk and deployment time.
This means a dependency is missing. Include the referenced metadata in your deployment scope and redeploy in the correct order.
No. Use generating-apex for Apex code and generating-flow for Flow authoring. This skill handles deployment orchestration only.
Full instructions (SKILL.md)
Source of truth, from forcedotcom/sf-skills.
name: deploying-metadata description: "Salesforce DevOps automation using sf CLI v2. TRIGGER when: user deploys metadata, creates/manages scratch orgs or sandboxes, sets up CI/CD pipelines, or troubleshoots deployment errors with sf project deploy. DO NOT TRIGGER when: writing Apex code (use generating-apex), building LWC components (use generating-lwc-components), creating metadata definitions (use generating-custom-object or generating-custom-field), or querying org data (use handling-sf-data)." metadata: version: "1.1"
deploying-metadata: Comprehensive Salesforce DevOps Automation
Use this skill when the user needs deployment orchestration: dry-run validation, targeted or manifest-based deploys, CI/CD workflow advice, scratch-org management, failure triage, or safe rollout sequencing for Salesforce metadata.
When This Skill Owns the Task
Use deploying-metadata when the work involves:
sf project deploy start,quick,report, or retrieval workflows- release sequencing across objects, permission sets, Apex, and Flows
- CI/CD gates, test-level selection, or deployment reports
- troubleshooting deployment failures and dependency ordering
Delegate elsewhere when the user is:
- authoring Apex code → generating-apex
- authoring LWC components → generating-lwc-components
- creating custom objects or fields → generating-custom-object, generating-custom-field
- building Flows → generating-flow
- doing org data operations → handling-sf-data
- authoring or testing Agentforce agents → developing-agentforce
Critical Operating Rules
- Use
sfCLI v2 only. - On non-source-tracking orgs, deploy/retrieve commands require an explicit scope such as
--source-dir,--metadata, or--manifest. - Prefer
--dry-runfirst before real deploys. - For Flows, deploy safely and activate only after validation.
- Keep test-data creation guidance delegated to
handling-sf-dataafter metadata is validated or deployed.
Default deployment order
| Phase | Metadata |
|---|---|
| 1 | Custom objects / fields |
| 2 | Permission sets |
| 3 | Apex |
| 4 | Flows as Draft |
| 5 | Flow activation / post-verify |
This ordering prevents many dependency and FLS failures.
Required Context to Gather First
Ask for or infer:
- target org alias and environment type
- deployment scope: source-dir, metadata list, or manifest
- whether this is validate-only, deploy, quick deploy, retrieve, or CI/CD guidance
- required test level and rollback expectations
- whether special metadata types are involved (Flow, permission sets, agents, packages)
Preflight checks:
sf --version
sf org list
sf org display --target-org <alias> --json
test -f sfdx-project.json
Recommended Workflow
1. Preflight
Confirm auth, repo shape, package directories, and target scope.
2. Validate first
sf project deploy start --dry-run --source-dir force-app --target-org <alias> --wait 30 --json
Use manifest- or metadata-scoped validation when the change set is targeted.
3. If validation succeeds, offer the next safe workflow
After a successful validation, guide the user to the correct next action:
- deploy now
- assign permission sets
- create test data via handling-sf-data
- run tests / smoke checks
- orchestrate multiple post-deploy steps in order
4. Deploy the smallest correct scope
# source-dir deploy
sf project deploy start --source-dir force-app --target-org <alias> --wait 30 --json
# manifest deploy
sf project deploy start --manifest manifest/package.xml --target-org <alias> --test-level RunLocalTests --wait 30 --json
# manifest deploy with Spring '26 relevant-test selection
sf project deploy start --manifest manifest/package.xml --target-org <alias> --test-level RunRelevantTests --wait 30 --json
# quick deploy after successful validation
sf project deploy quick --job-id <validation-job-id> --target-org <alias> --json
5. Verify
sf project deploy report --job-id <job-id> --target-org <alias> --json
Then verify tests, Flow state, permission assignments, and smoke-test behavior.
6. Report clearly
Summarize what deployed, what failed, what was skipped, and what the next safe action is.
Output template: references/deployment-report-template.md
High-Signal Failure Patterns
| Error / symptom | Likely cause | Default fix direction |
|---|---|---|
FIELD_CUSTOM_VALIDATION_EXCEPTION | validation rule or bad test data | adjust data or rule timing |
INVALID_CROSS_REFERENCE_KEY | missing dependency | include referenced metadata first |
CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY | trigger / Flow / validation side effect | inspect automation stack and failing logic |
| tests fail during deploy | broken code or fragile tests | run targeted tests, fix root cause, revalidate |
| field/object not found in permset | wrong order | deploy objects/fields before permission sets |
| Flow invalid / version conflict | dependency or activation problem | deploy as Draft, verify, then activate |
Full workflows: references/orchestration.md, references/trigger-deployment-safety.md
CI/CD Guidance
Default pipeline shape:
- authenticate
- validate repo / org state
- static analysis
- dry-run deploy
- tests + coverage gates
- deploy
- verify + notify
- When org policy and release risk allow it, consider
--test-level RunRelevantTestsfor Apex-heavy deployments. - Pair this with modern Apex test annotations such as
@IsTest(testFor=...)and@IsTest(isCritical=true)— see generating-apex for authoring guidance.
Static analysis now uses Code Analyzer v5 (sf code-analyzer), not retired sf scanner.
Deep reference: references/deployment-workflows.md
Agentforce Deployment Note
Use this skill to orchestrate deployment/publish sequencing around agents, but use the agent-specific skill for authoring decisions:
- developing-agentforce for
.agentauthoring, Agent Builder, Prompt Builder, and metadata config
For full agent DevOps details, including Agent: pseudo metadata, publish/activate, and sync-between-orgs, see:
Cross-Skill Integration
| Need | Delegate to | Reason |
|---|---|---|
| custom object creation | generating-custom-object | define objects before deploy |
| custom field creation | generating-custom-field | define fields before deploy |
| Apex authoring / fixes | generating-apex | code authoring and repair |
| Flow creation / repair | generating-flow | Flow authoring and activation guidance |
| test data or seed records | handling-sf-data | describe-first data setup and cleanup |
| Agent authoring and publish readiness | developing-agentforce | agent-specific correctness |
Reference Map
Start here
- references/orchestration.md
- references/deployment-workflows.md
- references/deployment-report-template.md
Specialized deployment safety
Asset templates
- assets/package.xml — manifest template covering common metadata types
- assets/destructiveChanges.xml — template for removing metadata from target orgs
Score Guide
| Score | Meaning |
|---|---|
| 90+ | strong deployment plan and execution guidance |
| 75–89 | good deploy guidance with minor review items |
| 60–74 | partial coverage of deployment risk |
| < 60 | insufficient confidence; tighten plan before rollout |
Completion Format
Deployment goal: <validate / deploy / retrieve / pipeline>
Target org: <alias>
Scope: <source-dir / metadata / manifest>
Result: <passed / failed / partial>
Key findings: <errors, ordering, tests, skipped items>
Next step: <safe follow-up action>
Related skills
More from forcedotcom/sf-skills and the wider catalog.

deploying-omnistudio-datapacks
Automate Vlocity DataPack deployment, validation, and retry workflows for OmniStudio/Industries configurations.

deploying-ui-bundle
Deploy UI bundle apps to Salesforce orgs with full metadata, permissions, and schema setup.

developing-agentforce
Build, modify, debug, and deploy Salesforce Agentforce agents using Agent Script.

developing-datacloud-code-extension
Develop and deploy custom Python transformations to Salesforce Data Cloud with init, scan, run, and deploy operations.

fetching-salesforce-docs
Retrieve and ground answers in official Salesforce documentation from developer.salesforce.com, help.salesforce.com, and other Salesforce-owned sources.

generating-apex
Production-grade Apex authoring for classes, triggers, and async jobs with built-in validation.