CQ Summer ’26 | Action Enhancements - Epic SQX‑52009

Page Overview

Purpose
This page documents the Documentation Outline for Epic SQX‑52009, which enhances the Action record lifecycle to improve transparency, governance, and usability.

The epic introduces:

• Comprehensive activity logging

• Clear approval visibility

• Governed periodic progress updates

• Correctable lifecycle transitions

• Improved UX clarity for Action and Action Plan fields

🎯 Epic Objective

The objective of Epic SQX‑52009 is to ensure that the Action record:

• Provides end‑to‑end lifecycle transparency

• Supports timely and governed progress updates for long‑running Actions

• Clearly communicates approval, implementation, and effectiveness status

• Allows safe lifecycle correction prior to approval submission

• Improves user understanding and data quality through clearer UI guidance

End Goal
Users can easily understand what happened, when it happened, and where the Action stands, without ambiguity or manual investigation.

🧭 Epic Intent

Problems Before

• No single, chronological view of Action lifecycle events

• Approval state required manual interpretation

• Long‑running Actions appeared inactive

• Users could not safely correct Actions marked Ready

• Periodic updates were ad‑hoc and ungoverned

• Field meanings were unclear, leading to inconsistent data entry

Outcomes After

• All Action, Implementation, Approval, and EC events are logged and visible

• Approval status is derived and visible at a glance

• Progress is tracked, reminded, and system‑governed

• Lifecycle mistakes can be safely corrected with guardrails

• Users clearly understand what information is expected in Action records

This epic transforms the Action record from a static task record into a governed lifecycle entity.

📋 Sub‑Tickets in Scope

🧩 Action Activity & Lifecycle Transparency

(Sub‑Tickets: 1, 4, 5)

Overview

All significant Action events are captured in a single History timeline, visible under the History tab, providing a complete audit trail.

🧩 Action‑Level Activities

(Sub‑Ticket: 1)

Overview

Action‑level lifecycle events are logged and displayed to provide a clear, chronological view of how an Action progresses through its lifecycle.

Where Activities Are Displayed

When a user navigates to an Action record:

• A Record Activities related list is displayed under the History tab

• Activities appear as they occur, in chronological order

Logged Action Activities

The following Action‑level activities are captured and displayed:

• Initiating Action

• Completing Action

• Skipping Action

• Extension Request

• Extending Action

• Rejecting Action

• Reopening Action

• Verifying Action

• Voiding Action

Scope Clarification

• This activity list is read‑only and intended for visibility

• Only the explicitly listed Action‑level lifecycle events are logged here

• No approvals, field‑level edits, or Effectiveness Check events are included in this section

Outcome

Action viewers can clearly understand what happened, when it happened, and how the Action lifecycle progressed, without ambiguity.

🧩 Implementation Activities

(Sub‑Ticket: 4)

Overview

Implementation‑specific lifecycle events are logged to provide a clear, chronological view of how an Action progresses through implementation and approval workflows.

Where Implementation Activities Are Displayed

When a user navigates to an Action record:

• A Record Activities related list is displayed under the History tab

• Implementation activities appear as they occur, in chronological order

Logged Implementation Activities

The following implementation‑level activities are captured and displayed:

• Implementation Submitted

• Implementation Change Submitted

• Implementation Change Approved

• Implementation Change Rejected

• Implementation Approved
  (supports partial approval)

• Implementation Rejected
  (supports partial rejection)

• Implementation Update

Scope Clarification

• These activities are read‑only and intended for visibility

• Partial approval and partial rejection scenarios are explicitly supported

• Only the listed implementation‑level events are logged here

• General Action lifecycle events and Effectiveness Check activities are handled in separate sections

Outcome

Action viewers can clearly understand implementation progress, approval decisions, and changes, including partial outcomes, without ambiguity.

🧩 Effectiveness Check Activities

(Sub‑Ticket: 5)

Overview

Effectiveness Check–related lifecycle events are logged to provide a clear, chronological view of Effectiveness Check progress for an Action.

Where Effectiveness Check Activities Are Displayed

When a user navigates to an Action record:

• A Record Activities related list is displayed under the History tab

• Effectiveness Check activities appear as they occur, in chronological order

Logged Effectiveness Check Activities

The following Effectiveness Check–specific activities are captured and displayed:

• Effectiveness Check Submitted

• Effectiveness Check Approved

• Effectiveness Check Rejected

• Effectiveness Check Recalled

Scope Clarification

• These activities are read‑only and intended for visibility

• Only the explicitly listed Effectiveness Check activities are logged here

• No approval logic, decision‑making, or workflow behavior is introduced in this section

• Action‑level and Implementation‑level activities are handled in separate sections

Outcome

Action viewers can clearly understand when Effectiveness Checks were submitted, approved, rejected, or recalled, providing full traceability without ambiguity.

🧩 Approval & EC Traceability

(Sub‑Tickets: 2, 9)

🧩 Approval History

(Sub‑Ticket: 2)

Overview

All approvals performed on an Action are displayed to provide clear visibility into approval decisions and lifecycle progression.

This allows action viewers to understand what approvals occurred, when they occurred, and what decisions were made.

Where Approval History Is Displayed

When a user navigates to an Action record:

• All approvals associated with the Action are displayed as part of the Action record view

• Approval entries are shown in chronological order

Approval Information Displayed

Each approval entry includes:

• Approval type / stage
  (e.g., Plan Approval, Implementation Approval, Verification / EC Approval)

• Decision
  (Submitted / Approved / Rejected)

• Timestamp

• Approver

• Comments or rationale, where applicable

Approval Model Clarification

• This is not a standard approval grid

• Partial approvals and partial rejections are supported

• Approval records are context‑aware and connected to:

  • Response

  • Inclusion

  • Approval decision details

This ensures approval history accurately reflects real‑world decision‑making.

Scope Clarification

• Approval history is read‑only and intended for visibility

• No approval actions are performed from this view

• Approval logic and workflow execution are handled elsewhere

Outcome

Action viewers can clearly understand how approval decisions influenced the Action lifecycle, including partial outcomes, without ambiguity.

🧩 Approval Indication

(Sub‑Ticket: 9)

Overview

Action Approval Status is displayed to provide quick, at‑a‑glance visibility into the current approval state of an Action.

This allows Action users to immediately understand where the Action stands in its approval lifecycle, without reviewing detailed approval history.

Where Approval Status Is Displayed

• Action Approval Status is displayed in the Compact Layout of the Action record

• Status is visible whenever an Action exists, especially when submitted for approval

Approval Status Derivation

Approval Status is derived automatically based on Action lifecycle state and approval outcomes.
It is read‑only and not user‑editable.

Supported Approval Statuses

✅ Plan Approval

• Plan Approval – Action submitted for plan approval

• Plan Approved – Plan approval approved

• Plan Rejected – Plan approval rejected

✅ Verification Approval

• Implementation Verification – Action complete and verification required

• Implementation Verified – Verification approved

• Verification Rejected – Verification rejected

✅ Implementation Approval

• Implementation Approval – Action submitted for implementation approval

• Implementation Approved – Implementation approved

• Implementation Rejected – Implementation rejected

✅ Cancellation (Skipped Action) Approval

• Cancellation Approval – Skipped Action submitted for approval

• Cancellation Approved – Skip approved

• Cancellation Rejected – Skip rejected

Scope Clarification

• Approval Status is informational only

• No approval actions are performed from this view

• Detailed approval records are available in Approval History (Sub‑Ticket 2)

Outcome

Users can quickly determine the current approval state of an Action, improving clarity and reducing the need to inspect approval history.

🧩 Timely Updates & Progress Governance

(Sub‑Tickets: 3, 7, 8)

🧩 Periodic Update

(Sub‑Ticket: 3)

Overview

Periodic Update allows an Action owner to manually log progress updates for long‑running Actions, without changing the Action’s lifecycle state.

Availability

• The Periodic Update Quick Action is available only when the Action status is Open

• Periodic Update is not available when the Action is:

  • Completed

  • Stopped

  • Submitted for approval

Performing a Periodic Update

When an Action owner performs a Periodic Update:

• Comment is required

• File attachments are supported

Activity Logging

• The comment entered during Periodic Update is logged in Record Activities as:

  • “Implementation Update”

• Attached files are added to the Action record

Scope Clarification

• Periodic Update is for progress indication only

• It does not change Action status

• It does not trigger approvals or workflow transitions

Outcome

Stakeholders can see ongoing progress for long‑running Actions, improving transparency without forcing lifecycle changes.

🧩 Periodic Update Tracking

(Sub‑Ticket: 7)

Overview

Periodic Update Tracking provides system‑driven monitoring and reminders for long‑running Actions, ensuring regular progress updates without manual follow‑ups.

This capability builds on Periodic Update (Sub‑Ticket 3) and is enabled through feature configuration.

When Periodic Update Tracking Applies

• Periodic Update Tracking applies only when the feature is enabled

• Tracking is active only while Action status is Open

Periodic Update Status Values

Tracking Behavior

✅ Action Open & Periodic Update Enabled

• Periodic Update Due Date is calculated using the configured interval

• Periodic Update Status = Pending

• Updates and due information are visible on the Action record

✅ Reminder Window Reached

• A Periodic Update Task is created:

  • Assigned to the Action Owner

  • Subject: “Periodic Update Due for Action <action number="">”</action>

  • Due Date = Periodic Update Due Date

• Reminder is shown on the Action record

• Periodic Update Status remains Pending

✅ Periodic Update Performed

• Periodic Update entry is logged on the Action

• Last Periodic Update Date is updated

• Next Due Date is recalculated

• Periodic Update task is marked Complete

• Periodic Update Status remains Pending

✅ Periodic Update Not Enabled

• Periodic Update tracking does not apply

• Periodic Update Status = N/A

✅ Action Skipped

• Periodic Update Status = N/A

• All existing Periodic Update tasks are deleted

• No reminders are generated

• Any approval‑related access restrictions follow system rules

✅ Action Completed

• Periodic Update Status = N/A

• All existing Periodic Update tasks are deleted

• No further Periodic Update reminders are created

Scope Clarification

• Periodic Update Status is system‑driven

• Status updates do not depend on manual user actions or approver behavior

• Periodic Update Tracking does not change Action lifecycle status

Outcome

Long‑running Actions remain visible, governed, and up‑to‑date, without adding approval or lifecycle complexity.

🧩 Periodic Update Feature Activation

(Sub‑Ticket: 8)

Overview

Periodic Update Feature Activation allows a CQ Admin to enable and configure Periodic Update behavior for Actions, including update intervals and reminder windows.

This configuration controls whether Periodic Update Tracking and reminders apply to Actions.

Configuration Location

• Periodic Update is configured through CQ Feature Activation metadata

• Configuration is performed by a CQ Admin

Feature Configuration Options

When activating the Periodic Update feature, the CQ Admin can define:

• Periodic Update interval
  (e.g., every X days / weeks / months)

• Notification / reminder window
  (timeframe before due date when reminders are triggered)

Applicability Scope

✅ CAPA Actions

• Periodic Update can be enabled for CAPA Actions

• Enabled Actions follow the full Periodic Update lifecycle:

  • Tracking

  • Reminders

  • Due dates

✅ Non‑CAPA Actions

• Periodic Update can also be enabled for Actions with parents other than CAPA

• Once enabled, these Actions follow the same lifecycle behavior as CAPA Actions

✅ Parent & Headless Actions

• Feature activation applies to:

  • Actions with a parent record

  • Headless Actions

• Behavior is consistent regardless of parent type

Design Alignment

• Periodic Update Feature Activation is treated similar to Action Verification or Action Extension

• If the feature is activated, Periodic Update functionality is applied uniformly to eligible Actions

Scope Clarification

• Feature Activation enables Periodic Update Tracking and reminders

• Actual tracking, task creation, and status behavior are handled by Periodic Update Tracking (Sub‑Ticket 7)

• Feature Activation itself does not log updates or change Action status

Outcome

CQ Admins can centrally control which Actions require Periodic Updates, ensuring consistent governance and system‑driven reminders.

🧩 Lifecycle Accuracy & Reversibility

(Sub‑Ticket: 6)

Overview

Undo Ready allows a CAPA Action owner to safely correct an Action that has been marked Ready, before it is submitted for approval, without requiring the approver to reject it.

Undo Ready Availability

• The Undo Ready Quick Action is available only when:

  • Action status is Ready

  • Action is not submitted for approval

Performing Undo Ready

When an Action owner performs Undo Ready:

• A Comment is required

• Upon submission:

  • A Record Activity “Undo Ready” is logged with the comment

  • Completion Date is cleared

  • Completed By is cleared

  • Action Status is set back to Open

Attempting Undo Ready After Submission

If the Action is already submitted for approval:

• Undo Ready is not allowed

• User is shown the error message:

  “Action is submitted for approval and cannot be pulled back. Please recall the approval if you need to pull back.”

Technical & Business Rule Notes

• Action submission state is derived from Action status, not tracked via a separate flag

• Undo Ready is status‑driven and permitted only when Action status is Ready

• If approval is recalled, Action may return to Ready and Undo Ready becomes available again

Outcome

Action lifecycle accuracy is preserved while maintaining approval integrity, allowing users to correct mistakes without breaking governance.

🧩 UX Clarity & Adoption

(Sub‑Ticket: 10)

Overview

Action Tooltip Improvements enhance user understanding and data clarity by updating tooltip text for Action Plans and Actions. These changes reduce ambiguity and improve correct data entry.

✅ Action Plan Tooltip Updates

The following tooltip updates apply to Action Plan fields:

• Plan Type
  Type of Action Plan

• Title
  Summary of action for easy reference

• Description
  Describe the action

• Due Date
  Expected completion date of the action. If specified, takes precedence over days required

• Days Required
  Enter elapsed days from approval to complete the action

• Is Complete
  Indicate if action is already completed

• Completed By
  If already complete, person who completed the action

• Completion Date
  If already complete, date the action was completed

✅ Action Tooltip Updates

The following tooltip updates apply to Action fields:

• Action Type
  Type of Action

• Action Plan
  Identifies source action plan from Investigation that created this action

• Title
  Summary of action for easy reference

• Description
  Describe the action

• Assignee
  Person assigned to perform the action

• Due Date
  Expected completion date of the action

• Completed By
  Person who completed the action

• Completion Date
  Date the action was completed

Scope Clarification

• Tooltip improvements are UX‑only

• No workflow, approval, or lifecycle behavior changes are introduced

• No backend logic or data model changes occur

Outcome

Users can better understand what information is expected in Action and Action Plan fields, improving data quality and reducing errors.

🔁 End‑to‑End Action Lifecycle

Action Created
   ↓
Action Open
   ├─ Action‑Level Activities logged                                   (ST‑1)
   │     • Initiated, Reopened, Skipped, Extended, Voided, etc.
   ├─ Periodic Update available (Quick Action)                         (ST‑3)
   │     • Comment required
   │     • Logged as “Implementation Update”
   │     • Files attached to Action
   ├─ Periodic Update Tracking (if feature enabled)                    (ST‑7, ST‑8)
   │     • Due Date calculated
   │     • Status = Pending
   │     • Reminder tasks created
   ├─ Implementation Activities logged                                 (ST‑4)
   │     • Implementation Submitted
   │     • Change Submitted / Approved / Rejected
   │     • Partial approvals / rejections supported
   ↓
Action Completed
   ├─ Completion Date set
   ├─ Completed By set
   ├─ Periodic Update Tracking disabled (Status = N/A)                 (ST‑7)
   ↓
Ready
   ├─ Action marked Ready
   ├─ Undo Ready available (if not submitted for approval)             (ST‑6)
   │     • Comment required
   │     • “Undo Ready” activity logged
   │     • Completion Date & Completed By cleared
   │     • Status → Open
   ↓
Submit for Approval
   ├─ Plan Approval (if applicable)                                    (ST‑2, ST‑9)
   ├─ Implementation Approval (if applicable)                          (ST‑2, ST‑9)
   ├─ Verification / EC Approval (if applicable)                       (ST‑2, ST‑9)
   ├─ Cancellation Approval (if Action is Skipped)                     (ST‑9)
   ↓
Approval Status Displayed
   ├─ Derived, read‑only Approval Status shown in Compact Layout        (ST‑9)
   │     • Plan Approval / Approved / Rejected
   │     • Implementation Approval / Approved / Rejected
   │     • Verification / Verified / Rejected
   │     • Cancellation Approved / Rejected
   ↓
Effectiveness Check Activities
   ├─ Effectiveness Check Submitted                                    (ST‑5)
   ├─ Effectiveness Check Approved                                     (ST‑5)
   ├─ Effectiveness Check Rejected                                     (ST‑5)
   ├─ Effectiveness Check Recalled                                     (ST‑5)
   ↓
Action Lifecycle Complete