"Revert to New" in Change Flows

[Lorena Larios]

Has anyone moved to flow designer for Change requests? How is "revert to new" supported in flows? 

[Naveen20 · Accepted solution]

Yes, many organizations have moved Change Request workflows to Flow Designer, and "Revert to New" is achievable but requires intentional design since Flow Designer doesn't have a native "revert" action the way the legacy workflow did.

How "Revert to New" worked in legacy workflows: The out-of-box Change workflow had explicit transitions that allowed reverting a change back to "New" (state = -5) from states like "Assess" or "Authorize." The workflow activity simply set the state back and re-entered the relevant workflow phase.

How to handle it in Flow Designer:

1. State-driven subflows approach (recommended): Build your change lifecycle as a main flow that listens for state changes on change_request. Use a decision step or branching logic that evaluates the current state. When someone triggers "Revert to New" (typically via a UI Action or workspace button that sets a flag or directly changes state), the flow picks it up and executes the revert logic — clearing approvals, resetting assignment groups, reverting risk/impact calculations, etc.

2. UI Action + Flow trigger pattern: Create a UI Action labeled "Revert to New" with conditions matching the allowed source states (Assess, Authorize, Scheduled, etc.). The UI Action triggers a subflow via sn_fd.FlowAPI.startSubflow() that handles the cleanup: setting state back to New, canceling any in-flight approvals via sn_approval.Approval API, and resetting relevant fields. This gives you fine-grained control over what "revert" actually does.

3. Approval rollback consideration: The trickiest part is handling approvals. In legacy workflows, reverting would automatically cancel pending approvals because the workflow context managed them. In Flow Designer, you need to explicitly handle this — either by using the "Cancel all pending approvals" flow action or by querying sysapproval_approver records tied to the change and setting them to "cancelled" via a Script Step.

4. State model validation: Make sure your Change state model (change_state_model or the state transitions configured in the Change Properties) actually allows the reverse transition. If you're using the new state model (New York+), the allowed transitions are enforced at the platform level regardless of whether you use workflows or flows. Check under Change > Administration > State Model to confirm backward transitions are permitted.

Key gotchas when migrating:

• Legacy workflows maintained execution context — they "knew" where they were in the lifecycle. Flow Designer flows are stateless by default, so you need to design your flows to evaluate current state fresh each time rather than relying on positional context.
• If you're running both the legacy workflow and a flow simultaneously during migration, you'll get duplicate processing. Deactivate the legacy workflow on change_request before activating your flow equivalent.
• The OOB "Change Management - Standard/Normal/Emergency" flows (if your instance version ships them) may already include revert handling — check what's available before building custom.

Bottom line: Flow Designer fully supports the "Revert to New" pattern, but it shifts from being an implicit workflow transition to an explicit, deliberately designed flow action. The upside is you get much more control over exactly what happens during the revert (which fields reset, which don't, notification behavior, audit trail, etc.)