The Four-State Lifecycle
Risk documents use the riskSpecification document type, which has a dedicated workflow with four states:
| State | Description | Who Can Transition |
|---|
| Draft | Initial state. The document is being authored or reworked. | Author (risk analyst) |
| In Review | Under formal review. Electronic signatures are being collected. | Reviewer initiates; approvers sign |
| Approved | At least one approver has signed. | Approver via electronic signature |
| Published | Released as part of the DHF. | Author or project lead |
Transition Actions
Each transition triggers specific system behaviors:
Send for Review (Draft —> In Review)
When an author sends a document for review, the system automatically:
- Adds default signers — Users with the
project_approver role are automatically assigned as approvers
- Sets the target status — Signers are configured to approve the transition to the “Approved” state
The AddDefaultSigners function handles this automatically. Authors do not need to manually assign reviewers.
Approve (In Review —> Approved)
The approval transition requires at least one electronic signature:
- Signature policy:
atLeastOne — A single approver signature is sufficient
- Auto-signature: Users with the
project_approver role can approve in a single action without a separate signature step
- Electronic signature: Captured in the Polarion audit trail with timestamp, user identity, and verdict
The atLeastOne policy means only one approver needs to sign. If your organization requires multiple independent reviewers, this policy can be changed to all in the workflow configuration.
Publish (Approved —> Published)
Publishing is a simple transition with no additional conditions. It represents the formal release of the risk document into the Design History File. Once published, the document is the official record.
Rework (Any State —> Draft)
Rework returns the document to Draft from any other state. This is the most consequential transition because it:
- Marks all workflow signatures as obsolete — via
MarkWorkflowSignaturesAsObsolete
- Resets all signature verdicts — via
ResetSignaturesVerdict
Both actions ensure that a reworked document requires complete re-approval. There is no “partial rework” — any change invalidates all previous approvals and forces the full review cycle.
Signature Invalidation
The signature invalidation behavior is critical for regulatory compliance. ISO 14971 requires that any change to a risk assessment triggers re-review. The workflow enforces this automatically:
| Scenario | Signatures | Approval Status |
|---|
| Document approved, no changes | Valid | Approved |
| Document reworked after approval | All signatures marked obsolete | Returns to Draft |
| Document reworked during review | All signatures reset | Returns to Draft |
| Document reworked after publication | All signatures invalidated | Returns to Draft |
Work Item Lifecycle (Within Documents)
Individual work items inside risk documents (risk records, failure modes, risk controls) follow a separate lifecycle from the document itself:
| State | Available For |
|---|
| Draft | New items being defined |
| In Progress | Items under active analysis (system elements only) |
| In Review | Items under peer review |
| Pending Approval | Items awaiting formal sign-off |
| Approved | Items that have passed review |
| Rejected | Items returned for rework |
| Obsolete | Items no longer applicable |
Risk records and failure modes are configured as fully read-only in standard Polarion forms. All edits must go through Nextedy risksheet. This ensures structured data entry, formula consistency (for RPN calculations and P1xP2 bucketing), and a clean audit trail.
Revision History
Risk documents support revision tracking through:
- Document version field — A
version custom field (float type) on the document
- Polarion revision system — Every save creates a new revision with timestamp and user identity
- Revision-aware risksheet links — The risksheet panel URL supports
&revision= parameters for viewing historical versions
- FMEA header table — Each document displays Item, Model, Version, Last Updated, Owner, and Core Team in a formatted header
The DFMEA template also includes an embedded history table for recording Date/Comments revision notes.
Document Templates
Four document templates are available for creating new risk analysis documents:
| Template | Location | Document Type | Used For |
|---|
| HARATemplate | RiskTemplates/HARATemplate | riskSpecification | HARA analysis documents |
| DFMEATemplate | RiskTemplates/DFMEATemplate | riskSpecification | DFMEA analysis documents |
| PFMEATemplate | RiskTemplates/PFMEATemplate | riskSpecification | Process FMEA documents |
| RiskControlPlanTemplate | RiskTemplates/RiskControlPlanTemplate | riskSpecification | Risk Control Plan documents |
Related Pages
