MOC Action Items vs Requirements

Requirements and Action Items work together to ensure regulatory compliance and operational readiness throughout the MOC workflow. However, they serve completely different purposes.

Requirements are predefined checklist items assigned independently or built into a Profile that automatically apply to every MOC of a given type. They structure what must happen during the Evaluation and Implementation stages and are configured in Settings > Requirements.
Action Items are follow-up tasks generated while working on a requirement. They capture specific or unplanned work discovered along the way and are tracked in the ACT module.

Requirements: Evaluation vs. Implementation

	Evaluation Requirements	Implementation Requirements
Purpose	Completed before Approval to help the Originator decide whether to move forward, void, or adjust scope based on risk/benefit analysis	Tasks that must happen during the MOC — safety reviews, drawing updates, notifications, etc.
Created by	MOC Power Users / Super Users — Settings > Requirements > Evaluation	MOC Power Users / Super Users — Settings > Requirements > Implementation
Key Setting	Mandatory vs. Recommended (set within a Profile)	Critical (must complete before startup) vs. Non-Critical (more flexible)
Assigned to	Individual, Job Role, Originator, or a default Evaluator	Individual, Job Role, Originator, or a default Implementer
Attachments	Smart Form/checklist or a linked network document (not both)	Smart Form/checklist or a linked network document (not both)
Due Dates	Days to Complete + Date Assigned = Due Date	Same calculation logic
Verification	Optional verifier reviews/approves or sends back	Optional verifier reviews/approves or sends back
Scope	Division-specific or company-wide (leave Division blank for company-wide)	Same scoping rule

About Profiles: Both requirement types are pre-built and reusable, and are typically bundled into Profiles so the right checklist automatically applies based on MOC category. This is what ensures consistency — the same requirements appear on every MOC of that type without anyone having to remember to add them. Keep profiles lean and purposeful; adding too many requirements makes them unwieldy and harder to maintain.

MOC Action Items

How They're Created

From within an Evaluation or Implementation requirement via the Action Items button while taking action on a requirement.
Via View > Action Items from the MOC In Process folder. MOC Users, Power Users, and Super Users can all create action items this way.
Auto-generated from a specific form answer, configured by a MOC Power User in Settings > Forms > Action Items, wired to a Radio Button or Checkbox field.

How They're Tracked

Live and are tracked in the ACT module — not in MOC Settings — though still visible from the MOC summary.
Each action item requires a clear owner — an individual or job role — so accountability is always obvious.
Support Priority and Classification fields (e.g., Preventive, Corrective) which affect how they appear in ACT reporting and dashboards.

How They're Scheduled

Governed by two fields: Assign in Stage (when the task is assigned) and Due in Stage (when it must be completed before the MOC can proceed).
Support Sub Action Items, which inherit the parent's Assign/Due in Stage settings by default.

When to Use Which

Use a Requirement to:

Hold a stage until something is documented, such as an engineering review.
Collect a standard form, questionnaire, or Process Hazard Analysis.
Capture a mandatory sign-off before the MOC advances.

Use an Action Item to:

Assign specific follow-up work to a person or job role.
Track field execution — procedure and drawing updates, installs, training.
Capture work discovered mid-change without touching the profile.

Why the Distinction Matters

Requirements are your governance layer — administrators design them in advance so every MOC of a given type gets the right scrutiny (e.g., a mandatory PSSR checklist for high-risk changes). They surface in MOC Dashboards.
Action Items are your execution layer — the ad hoc follow-up work a requirement uncovers (e.g., "update the P&ID," "retrain operators"), each with its own owner, due date, and tracking. They feed Action Item Dashboards in ACT.
Reporting differs too — auditing "did we run the right checklist" vs. "did the follow-up work get done" requires different reports and different dashboards.
Together — standardization where it counts, tailoring where it is needed.

Best Practices

Keep requirements high-level and repeatable — not micro-tasks.
Keep profiles lean and purposeful — only include requirements that apply to every MOC of that type. Requirements that only sometimes apply are better handled as action items.
Give every action item a clear owner (a person or a job role) so accountability is obvious.
Use Priority and Classification fields on action items to make ACT reporting more meaningful.
Use the MOC summary view to see requirements and action items together so nothing slips through.
Remember that requirements live in MOC Settings and MOC Dashboards, while action items live in ACT — go to the right place when reporting or auditing.