Treat activation as a deliberate gate. Build and test in a sandbox, deploy to production as inactive, review, then activate. The pattern adds friction but eliminates the class of incidents where someone configured and activated in one click without realizing what the click would do.
- Build and configure the artifact in a sandbox
Whether Flow, Validation Rule, Price Book, or Permission Set, build it in a sandbox first. Test against representative records. Activate in the sandbox to validate runtime behavior.
- Deploy to production through the normal pipeline
Change sets, source-tracked deploys, or DevOps Center. Most artifacts deploy as inactive by default; the activation step is separate from the deploy step.
- Review the deployed artifact in production before activating
Open the artifact in production setup. Confirm it matches the sandbox version. Confirm dependencies (referenced fields, classes, objects) exist.
- Get explicit authorization for activation
For change-controlled orgs, the activation step needs sign-off. Document who authorized and when. The audit trail entry is the compliance signal.
- Activate the artifact
Click the Activate button or check the Active flag. The artifact begins affecting production behavior immediately. Set a calendar reminder to check for downstream issues over the next 24 to 48 hours.
- Monitor for downstream effects
New Flow activation can affect record creates and updates. New Validation Rule activation can block previously-valid saves. New Permission Set assignment can change what users see. Watch the relevant signals for the first day.
- Document the activation in the change log
Date, artifact, version, who authorized, who activated. The change log is the audit trail the compliance review will reference later.
Active checkbox (Validation Rules, Workflow Rules, Price Books, Users), Version Activate button (Flows, Process Builder), Assignment-as-activation (Permission Sets).
Whether a change-control review is required before activation. Common in regulated environments.
For Flows: reactivate previous version. For Validation Rules and Workflow Rules: uncheck Active. For Permission Sets: bulk un-assign. Plan the rollback before activating.
SetupAuditTrail captures most activation events. Pull the trail for compliance review.
Confirm referenced fields, classes, and objects exist before activating. Missing dependencies produce runtime errors rather than setup-time blocks.
- Activating a new Flow version automatically deactivates the previous version. Plan the rollback before activating; you cannot have two versions active simultaneously.
- Permission Set activation through assignment is bulk. A change that affects 500 users assigned to a permission set lands all at once when the set is changed.
- Validation Rules activated mid-day affect every save from that moment on. Saves that were valid five minutes ago can fail; brief users before activating customer-facing rules.
- Inactive Price Book Entries silently disappear from Opportunity line item picklists. Deactivation looks small in Setup but is highly visible in selling workflow.
- User deactivation does not free record ownership. The records remain with the deactivated user as owner; reassign before or after deactivation as policy requires.