Activation
Activation in Salesforce is the explicit step that takes a configured artifact (a Flow, a Price Book, a Permission Set, a Workflow Rule, a Process Builder process, a Validation Rule, a User record) from a built-but-inactive state to a live state where the platform enforces or executes it.
Definition
Activation in Salesforce is the explicit step that takes a configured artifact (a Flow, a Price Book, a Permission Set, a Workflow Rule, a Process Builder process, a Validation Rule, a User record) from a built-but-inactive state to a live state where the platform enforces or executes it. Many Salesforce artifacts ship with an Active flag that defaults to off; the admin builds, tests, then activates when ready. Activation is the gate between configuration time and runtime behavior.
The pattern is consistent across the platform but the activation mechanism varies per artifact. Flows have a Version Activate button. Permission Sets have an Activate Users link to assign them. Validation Rules have an Active checkbox. Price Books have an Active checkbox. The unifying property is that an inactive artifact does not affect production behavior, and an active one does. Activation is one of the most consequential single clicks an admin makes; the artifact moves from sandbox-quality experiment to production-affecting rule the moment the box is checked.
Why activation is a deliberate gate, not a configuration detail
Which Salesforce artifacts require explicit activation
Most automation artifacts: Flows (Version Activate), Process Builder processes (Activate), Workflow Rules (Active checkbox), Approval Processes (Activate), Validation Rules (Active checkbox), Assignment Rules (Activate one at a time), Auto-Response Rules (Activate one at a time), Escalation Rules (Active checkbox). Most data artifacts: Price Books (Active checkbox), Pricebook Entries (Active checkbox at the entry level), Products (Active checkbox). Most security artifacts: Permission Sets (Assign to Users to take effect), Profiles (always-active by definition), User records (Active checkbox controls whether the user can log in). Each artifact's activation pattern follows the same logic: built first, activated when ready.
Flow activation and the version model
Flows have versions. The currently active version is what runs in production; new versions are built as drafts and tested before they replace the active one. Activating a new version automatically deactivates the previous active version (only one version can be active at a time). The previous version is still accessible as a draft and can be re-activated to roll back. The version model is the closest thing Salesforce has to a deploy-and-rollback pattern at the per-artifact level. Most admins underuse it; cloning the existing version, editing the clone, and activating the clone is the safe pattern, but many admins edit the active version directly and break production behavior.
Price Book activation and the implications for selling
Price Books and their Pricebook Entries both have Active flags. An inactive Price Book cannot be assigned to an Opportunity. An inactive Pricebook Entry cannot be added to an Opportunity Line Item. The two activations are independent; an active Price Book with all entries inactive is functionally useless. Deactivating a Price Book mid-quarter is a high-impact change that affects every in-flight Opportunity using it. Most teams treat Price Book activation as a quarterly governance event with explicit Finance and Sales Ops review.
Permission Set activation through assignment
Permission Sets do not have an Active checkbox in the traditional sense. A Permission Set is created and configured, then assigned to users; the assignment is the activation. Users with the permission set have the permissions; users without it do not. Mass assignment through the UI is one path; assignment through the SetupAuditTrail-friendly API path is another. Bulk activation across hundreds of users at once is common; deactivation through bulk un-assignment is the rollback path. The change log on Permission Set assignments is one of the most reviewed audit signals in regulated orgs.
User activation, deactivation, and license consumption
User records have an Active checkbox that controls whether the user can log in. Active users consume a license; deactivated users do not. Deactivating a user does not delete their data, history, or owned records; the record remains for audit and the user can be reactivated later. Most orgs deactivate users on their last day rather than deleting; the data integrity matters for compliance and reporting. Reactivating a user who left and returned years later is straightforward through the same Active checkbox. The license consumption math is what drives many user-management decisions.
Activation order and the dependency question
Some artifacts have activation dependencies. A Flow that calls an Apex action needs the Apex class to be deployed and active. A Permission Set that references a custom object needs the object to exist. A Validation Rule that references a custom field needs the field to exist. Activating an artifact whose dependencies are missing produces a runtime error rather than a setup-time block in most cases. Sequence matters during sandbox-to-production deploys; the deploy tool usually handles the order, but manual activation steps after the deploy still need to respect dependencies.
Activation as a change-control event
Many organizations treat activation as a formal change-control event distinct from configuration. The admin builds and tests in a sandbox, the change-control board reviews, an authorized admin activates in production. The activation step is what triggers the audit log entry that compliance teams care about. Building in production is often allowed for admins; activating in production is the gated act. This pattern adds friction but also adds confidence; many production incidents trace back to activations that happened without explicit review.
How to manage activation as a safe change-control step
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.
Trust & references
Cross-checked against the following references.
- Flow activation referenceSalesforce
- Setup Audit TrailSalesforce
Straight from the source - Salesforce's reference material on Activation.
- Activate a FlowSalesforce Help
- Validation RulesSalesforce Help
- Deactivate a UserSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. In which area of Salesforce would you typically find Activation?
Q2. Why is understanding Activation important for Salesforce admins?
Q3. Can a Salesforce admin configure Activation without writing code?
Discussion
Loading discussion…