Skip to main content

MOC Workflow

A Management of Change (MOC) follows a six-step lifecycle. Each step is handled by a specific role and has its own form, validation rules, and approval logic.

Lifecycle Overview​

Step A          Step B           Step C          Step D          Step E            Step F
Originator  →  Implementer  →  HSEQ Review  →  Approver  →  Implementation  →  Verification
(status "a")   (status "b")    (status "c")    (status "d")   (status "e")      (status "f")

At any step from B to D, the assigned user may decline the MOC, which halts progression and notifies stakeholders.

Step A — Originator (Part A)​

Actor: Any user initiating the change.

Form fields:

  • Description of the change (rich text)
  • Reason for change (dropdown with predefined options such as "Regulatory requirement", "Safety improvement", "Cost reduction", etc.)
  • Department of change
  • Affected departments and vessels (tag input)
  • Implementer assignment (user selector)
  • Departments to be informed (tag input)
  • Supporting attachments

Route: POST /api/newmoc

What happens on submission:

  1. A serial number is generated in the format {count}-{year} (e.g., 15-2026)
  2. An originator form document is created
  3. A chat room is created for the MOC
  4. The MOC document is created with status: "a"
  5. The implementer receives an email notification
  6. The MOC advances to status: "b"

Page: src/app/dashboard/Moc/create/page.tsx Form component: src/components/forms/mocForms/originatorForm.tsx

Step B — Implementer Assessment (Part B)​

Actor: The user assigned as Implementer.

Form fields:

  • Has the change been adequately detailed and assessed? (Yes/No)
  • Is the change necessary and justified? (Yes/No)
  • Change category (multi-tag)
  • Permanent or Temporary change
  • Target timeline (date picker)
  • Does it involve law/regulation?
  • Certification/PMS amendment required?
  • Legal review needed?
  • Training needs identified?
  • Business and public impact assessment
  • Approver and HSEQ reviewer assignment (user selectors)
  • Action plan and manuals/drawings plan

Route: POST /api/submit/implementer

Decline logic: If either "details assessed" or "necessary justified" is answered "No", the MOC is declined at stage B with a mandatory decline reason.

On approval: MOC advances to status: "c" and the HSEQ team receives an email.

Form component: src/components/forms/formComponents/implementerFormTable.tsx

Step C — HSEQ Review (Part C)​

Actor: HSEQ department user assigned to the MOC.

Form fields:

  • Has the change been adequately defined? (Yes/No)
  • Is the justification satisfactory? (Yes/No)
  • Has the risk assessment been adequately covered? (Yes/No)
  • Comments
  • Attachments

Route: POST /api/submit/hseq

Decline logic: If any of the three questions is answered "No", the MOC is sent back to status: "b" (Implementer) for revision.

On approval: MOC advances to status: "d" and the Approver receives an email.

Form component: src/components/forms/formComponents/hseqForm.tsx

Step D — Approver Review (Part D)​

Actor: The user assigned as Approver.

Form fields:

  • Have all changes been reviewed? (Yes/No)
  • Is the MOC approved? (Yes/No)
  • Has the implementer been informed? (Yes/No)
  • Comments
  • Attachments

Route: POST /api/submit/approver

Decline logic: If "MOC approved" is answered "No", the MOC is declined with a mandatory reason.

On approval: MOC advances to status: "e" for implementation.

Form component: src/components/forms/formComponents/approver.tsx

Step E — Implementation (Part E)​

Actor: The Implementer.

Form fields:

  • Has the MOC been circulated?
  • Was the implementation carried out as planned?
  • Was there any deviation during implementation? (triggers deviation sub-form)
  • Temporary MOC review details
  • Completion date
  • Does the MOC require an extension? (triggers extension sub-form)
  • When was the verifier informed?

Route: POST /api/submit/implementation

Deviation/Extension handling:

  • If a deviation or extension is flagged, the MOC returns to status: "b" for the implementer to address. A separate approval cycle is initiated.
  • Deviations and extensions are tracked in the extentionsAndDeviations field on the MOC document.
  • The endpoint POST /api/submit/deviation-extention handles marking individual deviations/extensions as resolved.

On completion (no deviations): MOC advances to status: "f".

Form component: src/components/forms/formComponents/implementation.tsx

Step F — Verification and Close-out (Part F)​

Actor: The HSEQ / Verifier user.

Form fields:

  • Is the action plan correct and complete?
  • Have manuals and plans been changed?
  • Have required trainings been completed?
  • Has feedback been completed?
  • Is the MOC effective?
  • Any improvement suggestions?
  • Close MOC confirmation
  • Comments and date

Route: POST /api/submit/verifier

On submission: MOC is marked as completed: true with status: "f". Completion emails are sent to all stakeholders.

Form component: src/components/forms/formComponents/verification.tsx

MOC Detail Page​

The central page for viewing and editing a MOC is located at:

src/app/dashboard/Moc/list/[moc_id]/page.tsx

This page orchestrates all six form steps. It determines which form the current user can edit vs. preview based on their role and the MOC's current status. A draggable navigation panel allows jumping between steps.

Key logic in this page:

  • previewOrEdit(moc, currentForm) — Returns whether the current user sees a read-only preview or an editable form
  • validate(formType, form) — Validates required fields before submission
  • submit(index, state, moc_id) — Routes the submission to the appropriate API endpoint

Cloning a MOC​

Any MOC can be cloned to create a new instance with pre-filled data:

  • Endpoint: POST /api/cloneMoc
  • Creates new originator, implementer, and implementation documents
  • Generates a new serial number
  • Sets cloned: true and links to the previous MOC
  • Starts the new MOC at status: "b"