The Release That Would Not Validate

All three errors point at the same root cause: the deployment was assembled by hand-picking components into a change set, so dependencies were left behind.

• 'Entity is not org-wide ready' on a flow means the flow references an object or field that does not exist (or is not deployed) in the target - typically a field added to the custom object but not included, or a field created in the sandbox after the change set was built.
• Missing custom label is a classic change-set omission: labels live in a separate metadata type and are easy to forget.
• 74% coverage is an org-wide figure, so it is not necessarily about the new classes. Something else in the org is dragging the average down, or a test class for the new trigger was not included.

Fix order:

1. Baseline the source. Retrieve the full metadata from the source sandbox and diff it against what is in the change set; then diff source against production. Rebuild the deployment from the diff rather than from memory.
2. Deploy in dependency order - objects, then fields, then custom labels and settings, then Apex, then flows, then Lightning pages, then profiles and permission sets - or use a source-tracked tool (SFDX/unlocked package/DevOps Center) that resolves dependencies automatically.
3. Reproduce with a Validate deploy into production before touching the real deployment; repeat until clean.
4. Fix coverage separately by finding which classes are failing, not by lowering the bar. If a legitimate gap in an unrelated legacy class is blocking, write a test for it - that debt will block every future release.

Do not 'fix' the flow error by re-saving the flow in production; that just hides the missing field.

Treat the hotfix as a separate, minimised deployment with its own validation, not as a subset of the release branch.

1. Source it from the right place. The UAT full sandbox is 70 days old, so its metadata does not match production and anything you pull from it risks carrying stale components, including overwriting the admin's recent production changes. Build the hotfix from a sandbox refreshed to, or very close to, current production - or from your source of truth after retrieving production.
2. Include only what is needed - the trigger, its test class, and any dependency it genuinely requires. Nothing else. Every extra component is a chance to drag in the release.
3. Validate into production first. A Validate deployment costs nothing and catches most failures. Note that specifying tests does not exempt you from the org-wide 75% requirement, so confirm production is comfortably above it before you start.
4. Quick deploy. After a successful validation, use the quick deploy option to skip re-running tests and cut the deployment window.
5. Schedule off-peak, confirm the rollback plan (previous version of the class retrievable, or destructive changes ready), and watch for the release work having already touched the same class - if it has, the hotfix and the release will conflict later.

The 48-hour pressure is real, but the failure mode to avoid is a rushed deployment that carries half a release and the admin's untested profile changes with it.

Right now, those changes are a live conflict with the release: the release contains six profiles and nine Lightning pages, and deploying them will either overwrite the admin's production-only work or fail. Neither outcome is acceptable, and the org has no way to tell which without looking.

Immediate actions:

1. Retrieve production metadata now and diff it against your source of truth - profiles, layouts, Lightning pages, and anything else the admin touched. Produce a concrete list; 'she changed some profiles' is not a change record.
2. Back-port the admin's changes into the development branch so they become part of the release rather than a casualty of it. Then the release and production agree, and you gain a rollback point.
3. Pause further direct changes during the release window, in writing, with the release manager's authority behind it.

Going forward, address the incentive, not just the rule - she did it because it was faster, and that is a process failure on your side as much as hers:

• Move as much as possible out of profiles into permission sets, so routine access changes stop being release-coupled metadata and can be managed safely in production without a deployment.
• Give a same-day path for small production-safe changes: a hotfix lane with a validate-first rule, not a blanket ban.
• Adopt source-tracked deployment so 'what is in production' is a fact rather than an archaeology exercise.

Leaving the drift unresolved and deploying anyway is the worst option available; you will find out what broke from users.