sf-deployment-strategies

Guides Salesforce metadata deployments using sf project deploy commands, test levels, and validate-plus-quick production workflows.

2|Updated Sep 12, 2026
One-click install
npx skills add https://github.com/grzmol/vibe-force --skill sf-deployment-strategies-grzmol
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sf-deployment-strategies
Source: https://github.com/grzmol/vibe-force/tree/main/skills/sf-deployment-strategies
Command: npx skills add https://github.com/grzmol/vibe-force --skill sf-deployment-strategies-grzmol

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Deploying Salesforce metadata safely is hard: test levels and coverage rules differ per org type, destructive changes have strict manifest rules, production deploys can burn entire change windows on test runs, and many metadata types (Profiles, Flows, picklists, sharing rules) fail in non-obvious ways. This Skill provides the decision tables, command patterns, and error catalogue needed to get metadata into an org without surprises. ## Core Features & Use Cases - Deployment mechanism selection: Decision tables for source deploy vs Metadata API vs change sets vs DevOps Center vs packaging, plus the full sf project deploy start/validate/quick/report/resume/cancel flag surface. - Production validate + quick deploy runbook: Step-by-step flow covering the 10-day validation window, coverage preconditions, the deploy-jobs.json state contract, hook-based production guards, and rollback options including pre-validated rollback packages. - Per-type gotchas and error catalogue: Documented traps for Profiles, Flows, custom settings, record types, picklists, sharing rules, layouts, and translations, plus an error-string-to-cause-to-fix catalogue for triage. - Use Case: You need to promote a release to production. The Skill walks you through generating a delta manifest, backing up the pre-deploy state, running sf project deploy validate with RunLocalTests, gating on coverage, then quick-deploying the validated job id inside the change window. ## Quick Start Ask the assistant to validate and quick-deploy the current release manifest to the production org using RunLocalTests with a pre-deploy backup.

Frequently Asked Questions about sf-deployment-strategies

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I deploy Salesforce metadata to production with sf CLI?

Run sf project deploy validate with --test-level RunLocalTests to run all tests without saving, then run sf project deploy quick --job-id with the returned job id. The validation stays valid for 10 days and the quick deploy skips the test run, finishing in minutes.

What is the difference between sf project deploy start, validate, and quick?

deploy start saves to the org and optionally runs tests; deploy validate runs tests without saving and returns a job id; deploy quick executes a previously validated job with no test run. Validate and quick are documented as production-only commands.

Which test level should I use for a Salesforce deployment?

Use RunLocalTests for production deploys and validations, which requires 75% org-wide coverage and some trigger coverage. RunSpecifiedTests requires each deployed class and trigger at 75% individually, and NoTestRun is only allowed on development orgs.

Can I use sf project deploy validate on a sandbox?

No, deploy validate and deploy quick are documented as production-only commands. The sandbox equivalent is sf project deploy start --dry-run --test-level RunLocalTests, which validates and runs tests without saving.

Why does my destructiveChanges.xml delete nothing?

Wildcards are not supported in destructive manifests, so every member must be listed explicitly. A package.xml containing at least the API version must also accompany the destructive manifest, even for a delete-only deploy.

Why did my Flow deploy activate the wrong version?

When a FlowDefinition is part of the deployment, its activeVersionNumber overrides the status field in the flow itself. Either omit flowDefinitions from the payload and control status on the Flow, or keep activeVersionNumber correct.