1. Freeze the release scope first
Write down the source org, target org, release owner, planned window, metadata types, data changes, integrations, and rollback owner. A review cannot be reliable while the package is still changing.
Treat “no data change” as an explicit statement, not an assumption. The same applies to permissions, scheduled jobs, integration endpoints, and destructive changes.
2. Capture the target-org baseline
Collect evidence close to the release window so the review represents the org that will actually receive the change. At minimum, review the following areas.
- API, storage, and platform limits that the release may consume.
- Security settings, login policy, health-check findings, and recent authentication failures.
- Active flows, triggers, scheduled jobs, and automation that touch the same objects.
- Profiles, permission sets, permission set groups, and field-level access affected by the change.
- Recent setup audit trail entries that could explain unexpected differences.
3. Compare meaning, not only file counts
An org comparison should separate expected release differences, accepted environment-specific differences, and unexplained drift. A large diff is not automatically dangerous, and a one-line permission change is not automatically safe.
For every unexplained difference, assign an owner and choose one action: include it, exclude it, document it as intentional, or stop the release until it is understood.
4. Turn findings into release decisions
Classify each finding by business impact, likelihood, detectability, owner, and required action. Then define the go/no-go threshold before the meeting. This prevents the loudest person in the room from becoming the release policy.
Minimum sign-off pack
- Frozen release manifest and named owners.
- Timestamped target-org baseline evidence.
- Source-to-target differences with a disposition for every unexplained item.
- Validation results, business smoke tests, and monitoring owner.
- Rollback trigger, rollback steps, and authority to invoke them.
Where the tools fit
Admin Toolkit for Salesforce can help gather read-only org review evidence, inspect permissions, explore schema, compare org metadata, and export supporting material. It does not replace release ownership, business acceptance, live validation, or rollback authority.