Walk me through the playbook for a major release that includes data model changes, code, and config.

A "major release" — multi-week project with new objects/fields, Apex, flows, page layouts, and security changes. The rollout playbook:

Pre-release (T-2 weeks):

1. Frozen scope. Lock the change set. Only critical bug fixes from here.
2. Sandbox parity. Refresh the staging Full Sandbox from production so it has current data + metadata. Apply all changes.
3. Regression test pass. End-to-end tests in staging: every user persona, every key journey.
4. Performance test. Run typical load scenarios on staging — flow executions, report runs, integrations — confirm no degradation.
5. Documentation. Release notes for every change, separated by audience: end-users, admins, integration owners.
6. Stakeholder sign-off. Demo to product owners, gather final approvals.

Release week (T-3 days):

1. Communicate maintenance window. Email users + integration owners. State what's changing, when, expected impact.
2. Freeze production changes. No ad-hoc changes during the freeze window — only the planned release.
3. Pre-deploy validation. In production, run a metadata-only validation deploy (using the validate-only flag in change set or sf project deploy validate). This catches many issues without committing.
4. Backup. For destructive changes (field deletion, object deletion), export data first.

Release day (T):

1. Communicate window start. Slack/email out: "Release in progress, please don't make changes."
2. Apply schema changes first. Custom objects, fields. Data model changes are foundational.
3. Apply Apex/code. Test classes run; if they fail the deploy fails — back out or fix.
4. Apply automation/flow. Activate after dependent fields exist.
5. Apply page layouts and Lightning pages. UX changes go last so users don't see broken pages mid-deploy.
6. Apply permission changes. Permission sets, permission set groups. Often last because they reference everything else.
7. Smoke test in production. Walk through key user journeys with a test user. Verify integrations are succeeding.
8. Communicate window end. "Release complete. Report issues to..."

Post-release (T+1 day to T+1 week):

1. Hypercare. Heightened support presence for 1-2 weeks. Daily standups to triage incoming issues.
2. Monitoring. Watch error rates, flow failures, integration logs.
3. Quick fixes. Plan a follow-up release in a week to clean up small issues.
4. Retrospective. What worked, what didn't, what to change next time.

Rollback plan:

• Identify, before the release, what's reversible and what isn't.
• Reversible: code, flows, validation rules (you can deploy old versions back).
• Irreversible: deleted fields, deleted objects, schema changes that destroyed data.
• For irreversible changes, plan to fix forward, not rollback.
• For reversible parts, keep the prior version's metadata in a "rollback" change set ready to apply.

Common pitfalls:

• Over-scoping. Big releases compound failure modes. Smaller, more frequent releases are safer.
• Insufficient sandbox testing. Full Sandbox + production-realistic data is the only environment that catches scale-related bugs.
• No rollback plan for irreversible changes. Define "fix forward" for those before the release.

Modern teams target continuous deployment with smaller, more frequent releases, but for organisations stuck on quarterly release cycles, this playbook keeps risk manageable.