salesforce-live-change-approval-protocol

Salesforce Live Change Approval Protocol

Purpose

This skill is a refusal-by-default gate for any proposed mutation to a live Salesforce production org. It exists because production org changes carry irreversible risk — data exposure, broken automation, permission widening, and revenue-logic corruption can all result from unreviewed deployments. No live-mutation advisory may proceed until all ten required preconditions are confirmed present and documented.

Important: This repository is a markdown marketplace for advisory workflows. This protocol governs checklist-based advisory review, not real org executions. Live org mutations require human authorization through your organization's actual change management process.

When to use

• Any proposed change to a Salesforce production org is under discussion.
• A deployment is being planned and must be evaluated for approval-readiness.
• A change request has been submitted and needs precondition verification.
• An escalation gate (live-mutation from salesforce-risk-taxonomy) has fired.

When not to use

• The change targets only sandboxes or scratch orgs with no production impact.
• You need read-only review of exported metadata — use the appropriate domain review skill (salesforce-metadata-review-skill, salesforce-flow-automation-review-skill, etc.).
• You need to classify matter types — use salesforce-risk-taxonomy.
• You need a structured handoff — use salesforce-case-capsule.

Minimum payload (required inputs)

The following ten preconditions must ALL be present. If any is missing, the skill outputs STOP and lists the missing items.

1. target_org_identity — A placeholder identifier for the target org (never a real org ID or credentials). Environment type must be confirmed as production.
2. environment_type — Must be production. If sandbox or scratch, this protocol does not apply.
3. user_identity — The role or placeholder identity of the person authorizing the change (never a real username, email, or SSO ID).
4. permission_scope — The permissions held by the deploying identity. Must be documented; "admin" alone is insufficient.
5. change_ticket — A reference to an approved change management ticket (e.g., Jira, ServiceNow, Salesforce Cases). Must exist and be in approved state.
6. approval_state — The formal approval status. Must be approved by a named human owner. pending or draft → STOP.
7. dry_run_or_deployment_preview — Evidence that the change was previewed in a comparable environment (check-only deploy output, sandbox result, or equivalent). Must be present.
8. backup_rollback_plan — A documented plan for reversing the change if it fails. Must name the rollback mechanism and estimated recovery time.
9. test_evidence — Test results demonstrating the change is safe. Must include test class coverage (Apex) or equivalent automated evidence. Must meet org threshold.
10. post_change_verification_plan — Steps to verify the change is working correctly after deployment. Must be documented before deployment begins.