Force Actions

Force actions are privileged operations that allow Instance Heads and Deputy Heads to bypass normal execution rules and manually advance or terminate steps. They are designed for exceptional circumstances when normal step execution cannot proceed — for example, when evidence cannot be uploaded, work was completed offline, or a step is blocked by an external factor.

Caution

Force actions bypass validation and should be used sparingly. Every force action is logged with a mandatory reason and highlighted in the execution log for audit purposes.

---

Available Force Actions

RAMP provides three force actions for steps, plus a force cancel action for the entire instance.

Force Complete (F-OK)

Purpose: Mark a step as completed without passing normal validation checks.

What it bypasses:

• Evidence requirements (if the step has the Requires Evidence setting)
• Child step completion checks
• Normal completion validation rules

When to use:

• Work was completed offline and the system was not updated at the time
• Evidence was submitted through an external channel (email, ticket system)
• Technical issues prevent normal completion through the UI
• The step is no longer relevant but must be marked complete for execution to proceed

Example scenario: Evidence files are too large to upload (5 GB video). The operator uploaded screenshots showing key timestamps and documented the full file location on a shared drive. The Instance Head uses Force Complete with a reason referencing the external storage location.

Force Skip (F-SKIP)

Purpose: Skip a step that the template does not allow to be skipped.

What it bypasses:

• The template’s IsSkippable setting
• Child step status checks
• Normal skip validation

When to use:

• The step is not applicable in the current context
• The template incorrectly marked the step as non-skippable
• An external factor makes the step unnecessary
• A workaround or alternative procedure was used instead

Example scenario: A regulatory requirement changed mid-execution, making a compliance verification step unnecessary. The Instance Head uses Force Skip and documents the regulatory change in the reason field.

Force Abort (F-ABORT)

Purpose: Mark a step as failed/aborted when normal abort flow is insufficient.

What it bypasses:

• Normal abort validation
• Child step status checks

When to use:

• An insurmountable blocker prevents the step from being completed
• A critical error or failure occurred that cannot be resolved
• Work was attempted but was unsuccessful, and execution must continue
• The failure needs to be documented and the team must move on

Example scenario: A required external system has been unavailable for three days despite multiple escalation attempts. The Instance Head uses Force Abort and references the support ticket number in the reason.

---

Who Can Use Force Actions

Danger

Only Instance Head and Deputy Head roles can perform force actions. This restriction is intentional — even Super Users cannot use force actions to prevent accidental use at the system level.

Role	Can Use Force Actions?
Instance Head	Yes
Deputy Head	Yes
Global Instance Head	Yes
Global Instance Deputy Head	Yes
Executor	No
Editor	No
Observer	No
Super User	No

---

Using Force Actions

Force action buttons appear only for steps in Started, Running, or Paused status, and only when you have the Instance Head or Deputy Head role.

1. Select the step that requires a force action in the execution view
2. Locate the force action buttons below the standard action buttons:
   • FORCE COMPLETE (red text)
   • FORCE SKIP (orange text)
   • FORCE ABORT (red text)
3. Click the appropriate force action button
4. A confirmation dialog opens with a red warning banner
5. In the dialog:
   • Reason (mandatory, minimum 10 characters): Explain why normal execution cannot proceed, what was attempted, and any external factors
   • Consent checkbox: Check “I hereby approve this force action and understand the implications”
6. Click Confirm to execute the force action
7. The step transitions to its new status immediately

Force Action Dialog Details

The confirmation dialog includes several safeguards:

Warning banner: A red alert box reads “FORCE ACTION - USE WITH CAUTION. This action bypasses normal validation. Use only when necessary.”

Action-specific warnings:

• Force Complete: “This will mark the step as completed without validation. Ensure work is actually done.”
• Force Skip: “This will skip the step even if template prohibits skipping. Document reason carefully.”
• Force Abort: “This will mark the step as failed. This may affect subsequent steps and overall instance completion.”

Reason field requirements:

• Mandatory — the confirm button remains disabled until a reason is entered
• Minimum 10 characters enforced
• Should be detailed and specific for audit purposes

Consent checkbox: Mandatory — must be checked before the confirm button becomes active. Text reads: “I hereby approve this force action and understand the implications.”

---

Child Step Cascade

When a force action is performed on a parent step, all child steps in non-terminal states are automatically aborted. This cascade behavior ensures that the step tree remains in a consistent state.

How Cascade Works

1. You perform a force action (F-OK, F-SKIP, or F-ABORT) on a parent step
2. RAMP identifies all child steps in Pending, Started, Running, or Paused status
3. Each identified child step is immediately transitioned to Aborted status
4. The cascade recurses to grandchildren and all descendants
5. Each aborted child receives a skip reason: “Abort forced because step ‘[Parent Title]’ was finished with [F-OK/F-SKIP/F-ABORT]”
6. Each cascaded abort is logged individually in the execution log
7. Status changes are broadcast via SignalR to all connected users

Danger

The cascade is immediate and irreversible. Once a force action is confirmed on a parent step, all non-terminal child steps are aborted and cannot be recovered. Review the step hierarchy carefully before confirming.

Cascade Scope

Child Step Status	Affected by Cascade?
Pending	Yes — set to Aborted
Started	Yes — set to Aborted
Running	Yes — set to Aborted
Paused	Yes — set to Aborted
Completed	No — already terminal
Skipped	No — already terminal
Aborted	No — already terminal
Cancelled	No — already terminal

---

Force Cancel Instance

In addition to step-level force actions, Instance Heads can force-cancel the entire instance, ending all execution immediately.

1. Click Force Cancel in the instance header
2. Provide a reason for the cancellation (mandatory)
3. Confirm the action
4. All running and pending steps are cancelled
5. The instance transitions to Cancelled status

Caution

Force cancelling an instance is a terminal action. The instance becomes read-only and cannot be resumed. All in-progress steps are stopped and marked as cancelled.

---

Audit Trail for Force Actions

All force actions are recorded with full audit detail and are visually distinguished in the execution log.

What Is Logged

Each force action entry includes:

Field	Description
Action type	FORCE_COMPLETE, FORCE_SKIP, or FORCE_ABORT
Step ID and title	Which step was affected
User	Who performed the force action
Timestamp	Exact date and time
Reason	Full text of the provided reason
IsForceAction flag	Special marker distinguishing force actions from normal actions
Cascaded children	Which child steps were aborted as a result (if applicable)

Visual Indicators

Force action entries in the execution log are displayed with a red background, making them immediately visible when scrolling through the log. This visual distinction helps reviewers quickly locate and examine force actions during audit.

Viewing Force Action History

Execution Log

1. Open the execution view for the instance
2. Navigate to the Notes panel (right side)
3. Click the Execution Log tab
4. Force actions appear with a red background
5. Use the Force Actions Only filter to isolate them

Instance History

1. Open the instance detail page
2. Navigate to the History tab
3. All instance changes, including force actions, are listed
4. Filter by action type to find force actions

---

Writing Good Force Action Reasons

The reason field is your permanent record explaining why a force action was necessary. Auditors and future reviewers will rely on this text.

What to Include

• Why normal execution could not proceed
• What was attempted before resorting to the force action
• External references: ticket numbers, email confirmations, meeting decisions
• Evidence location: where supporting documentation can be found if not uploaded to RAMP

Examples

Poor reason: “Needed to move forward”

Good reason: “External vendor API was down for 3 days (incident ticket INC-12345). Work was completed manually via phone confirmation from vendor support on 2026-01-15. Email confirmation from vendor stored in ServiceNow ticket. Proceeding with Force Complete to unblock dependent steps.”

Poor reason: “Not needed”

Good reason: “Regulatory requirement SOX-4.2.1 was superseded by updated guidance issued 2026-01-10 (ref: compliance memo CM-2026-003). Step is no longer applicable. Confirmed with compliance team lead Sarah Chen via Slack on 2026-01-12.”

---

Common Scenarios

Evidence Cannot Be Uploaded

The step requires evidence, but files are too large or in an incompatible format.

Recommended approach:

1. Upload what you can (smaller files, screenshots)
2. Add an execution log comment with the location of the original files
3. Use Force Complete with a reason referencing the external storage

Step Cannot Be Completed Due to External Blocker

A technical issue outside the team’s control prevents step completion.

Recommended approach:

1. Document the blocker in the execution log with ticket references
2. Escalate to the Instance Head
3. Instance Head decides: Force Skip (if the step can be deferred) or Force Abort (if the failure must be recorded)

Work Was Completed Offline

The system was unavailable during execution; work was performed manually.

Recommended approach:

1. Document the manual work in the execution log
2. Reference any offline records (paper forms, emails)
3. Use Force Complete with a detailed reason

Duplicate Work

Step work was already completed in a previous instance or different procedure.

Recommended approach:

1. Verify that the work was truly completed
2. Reference the instance and step where it was done
3. Use Force Skip with a reason citing the original execution

---

Best Practices

1. Exhaust normal options first: Before using a force action, check whether the step can be completed, skipped, or resolved normally
2. Provide detailed reasons: The reason field is auditable — treat it as formal documentation
3. Document external evidence: Reference ticket numbers, email threads, and meeting decisions
4. Communicate with the team: Post an execution log comment explaining the situation before or after the force action
5. Review cascade impact: Before force-acting on a parent step, review how many child steps will be affected by the cascade
6. Address root causes: If the same force action is needed repeatedly, consider updating the template to reflect the actual workflow

---

Related topics

Step Actions Execute steps with granular completion statuses, skip, pause, resume, and manage execution modes

Status Flow Understand instance and step status lifecycles, transitions, and the Reset to Draft feature