These use cases illustrate the problem space and the expected behavior of the Workflow Action Policies system. They cover both Abandon and Force Complete actions across platform-wide and college-specific scenarios.
- Workflow action: A manual action available to authorized users from the workflow three-dot menu (e.g. Abandon, Force Complete).
- Policy: A data row that defines when a workflow action should be blocked and what message to show.
- Platform-wide policy: A policy with no owner — applies to all colleges by default.
- College-specific policy: A policy scoped to a College or CollegeSystem — applies only to workflows owned by that entity.
- Condition: A criterion that must be true for a policy to fire. Multiple conditions on a policy are AND'd; multiple policies for the same action are OR'd.
Context: Certain steps — ApprovalStep with "Application" in the name,
WaitForApplicationResponseStep, CollegeReviewAdmissionApplicationFailureStep —
represent in-flight application processing. Abandoning while these steps are active
disrupts the application lifecycle and leaves external systems in an inconsistent state.
Current behavior: Hard-coded in StudentTerm#prevent_abandon_based_on_active_active_flow_steps?.
Expected behavior with policies:
- Policy fires when any of these steps is active on the workflow.
- The Abandon option is shown as disabled with a reason such as: "This registration cannot be abandoned while an application review is in progress."
- Applies to all colleges by default.
Context: Missouri State University leaves registrations on the
CollegeVerifyAlternatePaymentStep indefinitely — the student is already registered
in their SIS and the college treats this step as a long-term holding state. Abandoning
a registration at this step would remove it from DE while it remains active in MSU's SIS.
Current behavior: Was previously restricted, accidentally re-enabled when MSU's payment workflow was updated in 2025. Currently broken/unresolved.
Expected behavior with policies:
- A college-scoped policy for MSU fires when the workflow is active on
CollegeVerifyAlternatePaymentStep. - Abandon is shown as disabled: "Registrations at the College: Verify Alternate Payment step cannot be abandoned for this college."
- Does not affect other colleges with the same step type.
UC-A3 — College-specific: UConn cannot abandon at the pending application response step (DUAL-16722)
Context: UConn routes registrations through an application workflow. When a
registration is on PendingApplicationResponseStep (or equivalent), the student may
have paid by credit card. Abandoning at this point prevents payment capture while the
registration may already be complete in UConn's SIS.
Current behavior: Unresolved/blocked.
Expected behavior with policies:
- A college-scoped policy for UConn fires when the workflow is active on the relevant step.
- Abandon is shown as disabled: "This registration cannot be abandoned while awaiting application response. If payment was submitted, please process it first."
Context: Bridgeport has steps that would normally be blocked by a platform-wide rule (UC-A1), but Bridgeport's workflow is structured differently and they need to be able to abandon at those points.
Current behavior: Handled via an allow_abandon: true parameter on individual step
definitions in the workflow YAML. This is a hidden, undocumented escape hatch that only
platform engineers can configure.
Expected behavior with policies:
- The platform-wide policy from UC-A1 does not apply to Bridgeport because a college-scoped policy for Bridgeport overrides it (no restriction condition = always allowed).
- Makes the exception visible and manageable without touching workflow definitions.
Force Complete is a new workflow-level action (see IDEA-338 / DUAL-18685) that allows authorized users to mark any active workflow as complete, bypassing remaining steps. Unlike Abandon, it runs the workflow's completion step to produce a proper completed state.
Context: For most workflows in most states, a college admin or superadmin should be able to Force Complete without any additional restrictions beyond their role.
Expected behavior:
- No policies configured → Force Complete is available whenever the user has permission.
- Confirmation modal requires a reason (cannot be undone).
Context: A student paid by credit card. The payment capture step has run (indicated by a fields key being present), but the payment processing step has not yet completed (its fields key is absent). Force Completing the workflow at this point would mark the registration complete without settling the payment.
Expected behavior with policies:
- A platform-wide policy fires when
cc_payment_captured_atis present ANDcc_payment_processed_atis absent in the workflow fields. - Force Complete is shown as disabled: "A credit card payment has been captured but not yet processed. Please process the payment manually before completing this registration."
- Once processing completes (key becomes present), the rule no longer fires and Force Complete becomes available again.
Context: A college manually registered a student in their SIS before any payment steps ran in DE. They want to Force Complete the DE workflow to close it out. No payment has been captured or processed.
Expected behavior:
- The payment policy (UC-FC2) does not fire because
cc_payment_captured_atis absent. - Force Complete proceeds normally.
- The support team does not need to intervene.
Context: A college has a workflow step that performs a critical external integration (e.g. SIS enrollment submission). They want to prevent Force Completing a registration if that integration step has not yet run.
Expected behavior with policies:
- The college creates a college-scoped policy for their specific step class and
step_state: not_executed. - Force Complete is blocked: "The SIS enrollment submission has not been sent. Please contact support to complete this registration manually."
- No code change or deployment required.
Context: A college admin opens the three-dot menu on a registration. The workflow has an active policy that blocks the Abandon action.
Expected behavior:
- Abandon is visible in the menu but rendered as disabled (grayed out).
- A tooltip or inline message shows the
restriction_reasonfrom the triggering policy. - Force Complete follows the same pattern.
- Neither action is silently hidden — users always know what is available and why.
Context: Both Abandon and Force Complete are irreversible actions that require the user to provide a reason.
Expected behavior:
- A single shared confirmation modal is parameterized by action type.
- Modal shows action title ("Abandon" or "Force Complete"), an irreversibility warning, and a required reason textarea (max 200 characters).
- On confirm, the reason is recorded in the audit trail.
Expected behavior:
- Full CRUD for workflow action policies in Active Admin.
- Filterable by action type, owner, target object type, category.
- Readable via Insights API endpoints.
Expected behavior:
- College admin UI shows platform-wide policies that apply to their college (read-only).
- They can create, edit, and delete policies scoped to their own college.
- They cannot see or modify policies for other colleges or platform defaults.