Skip to main content

PCR Workflow

A Procedure Change Request (PCR) follows a signature-based workflow where multiple parties review and sign off on a proposed procedure change.

Lifecycle Overview​

Originator creates PCR  →  Affected Parties sign  →  Sequential Signature Chain  →  Completed
     (status: "pending")                                                            (status: "finished")

Unlike MOCs, PCRs do not have distinct form-based stages. Instead, they use a signature collection model where designated roles sign in sequence.

Creating a PCR​

Actor: Any user (the Originator).

Form fields:

  • Is this a new suggestion? (Yes/No)
  • Is this a procedure change? (Yes/No)
  • Is it safety critical? (Yes/No)
  • Manual/Procedure reference (rich text)
  • Suggestion details (rich text)
  • Reason for change (rich text)
  • Peer review toggle
  • Originator attachments

Two tables are included in the creation form:

Affected Parties Table​

Dynamic rows where the originator selects users who are affected by the procedure change. Each row has:

  • Name (user dropdown)
  • Signature (to be filled by the affected party)
  • Comments

Signatures Table​

Fixed rows representing the signing chain. Each row has:

  • Role name (preset)
  • Signature
  • Date
  • Comments

The preset signature roles, in order:

  1. Change Originator
  2. VP Fleet Management
  3. HSEQ Coordinator
  4. Group HSEQ Manager
  5. Director HSEQ
  6. President

Route: POST /api/pcr

On creation:

  1. A serial number is generated
  2. The PCR is saved with status: "pending"
  3. Email notifications are sent to VP Fleet Management, all admins, and all affected parties

Page: src/app/dashboard/pcr/create/page.tsx Form component: src/features/pcrForms/components/initationPcr.tsx

Signature Collection​

Once a PCR is created, signatures are collected sequentially:

  1. The next role in the signing chain receives an email notification
  2. That user signs in the PCR tracking view
  3. Upon signing, the system automatically notifies the next role
  4. This continues until all signatures are collected

Signature endpoint: POST /api/pcr/signatures

Affected parties endpoint: POST /api/pcr/affectedParties

Completion logic: When all signatures in both the signatures table and affected parties table are collected, the PCR status is set to "finished" and completion emails are sent.

The signing logic is managed by utilities at src/features/allPcr/utils/pcrShowUtils.ts:

  • calculateDisabledSignatures() — Determines which signature fields should be disabled based on current progress
  • shouldUserSign() — Checks if the current user is the next expected signer
  • getNextPendingSignature() — Returns the next role that needs to sign

PCR Tracking View​

The PCR tracking page is located at src/app/dashboard/main/allPcr/page.tsx and renders the AllPcrWrapper component.

Each PCR is displayed as an expandable card (singlePcrDisplay.tsx) showing:

  • Originator information and form data
  • Affected parties table with signature status
  • Signatures table with signing progress
  • Chat integration
  • Status badge (in progress / completed)

Filters available:

  • Status (All / Completed / In Progress)
  • Role (Originator / Affected Party)
  • Date range
  • Text search (serial number, originator name)

Cloning a PCR​

PCRs can be cloned via POST /api/clonePcr:

  • Resets all signatures and affected party signatures to unsigned
  • Generates a new serial number
  • Sets cloned: true and stores the previous serial number
  • New PCR starts with status: "pending"