TestAuto2 implements two distinct workflows: Document workflows (for LiveDocs/modules) and work item workflows (for individual safety records). This page covers document workflows. See Risk Specification Workflow for risk analysis document workflows. Document Workflow States
The standard document workflow defines six primary states and two closure states, enabling progressive maturity gates through formal review cycles:
| State | ID | Description | Editable | Assignee Required | Signatures Cleared |
|---|
| Draft | draft | Initial state for new documents. Fully editable, no approval requirements. Suitable for iterative development and content creation. | ✓ Yes | No | N/A (initial) |
| In Review | inReview | Peer review state. Document submitted for technical review by assigned reviewers. Editable but under review. | ✓ Yes | Yes | N/A (unchanged) |
| Pending Approval | pendingApproval | Formal approval gate state. Document awaiting formal signatures from project approvers. Read-only recommended. | ✗ No | Yes | No (active) |
| Approved | approved | Formally approved by required signers. Represents acceptance by formal review authority. Still editable if changes needed. | ✓ Yes | Yes | No (retained) |
| Published | published | Final released state. Document is frozen for compliance purposes and serves as baseline for downstream activities. | ✗ No | Yes | No (retained) |
| Rejected | rejected | Formal rejection requiring rework. Document did not meet approval criteria. Reason documented in resolution field. | ✗ No | Yes | ✓ Yes (cleared) |
| Obsolete | obsolete | Deprecated or superseded document. Retained for traceability but no longer active. Marked with obsolescence reason. | ✗ No | Yes | ✓ Yes (cleared) |
Document Workflow Actions
Actions represent user-initiated transitions that move documents through the workflow. Each action may have preconditions (mandatory fields) and postconditions (automatic field updates):
Send for Review
Purpose: Transition document from draft to in-review state, initiating formal peer review cycle.
| Property | Value |
|---|
| From State | draft |
| To State | inReview |
| Action ID | sendForReview |
| Preconditions | Assignee field must be set |
| Postconditions | None |
| Auto-Assignments | None |
| Signature Changes | None |
Approve
Purpose: Transition document from in-review to approved state upon receipt of required formal signatures.
| Property | Value |
|---|
| From State | inReview |
| To State | approved |
| Action ID | approve |
| Preconditions | At least one approver signature with “approved” verdict required; no disapproved signatures |
| Postconditions | Resolution field must be filled |
| Auto-Assignments | None |
| Signature Changes | None (retained) |
atLeastOneApprovedAndNooneDisapproved — requires minimum one positive approval, blocks if any signature marked disapproved.
When to use: When all assigned reviewers have completed review and at least one formal approver has signed approval.
Example: Project approver signs FMEA document, transitioning to approved status.
Publish
Purpose: Transition document from approved to published state, indicating final release and baselined status.
| Property | Value |
|---|
| From State | approved |
| To State | published |
| Action ID | publish |
| Preconditions | None |
| Postconditions | None |
| Auto-Assignments | None |
| Signature Changes | None (retained) |
Rework
Purpose: Return document to draft state from any workflow state (in-review, approved, published, rejected, or obsolete) to enable corrections or updates.
| Property | Value |
|---|
| From States | inReview, approved, published, rejected, obsolete |
| To State | draft |
| Action ID | rework |
| Preconditions | None |
| Postconditions | All workflow signatures automatically marked obsolete; signature verdicts reset to cleared |
| Auto-Assignments | None |
| Signature Changes | ✓ Marked obsolete and cleared |
Rework invalidates all existing approvals. After rework, the document must repeat the full review-approval cycle before republication.
Reject
Purpose: Formally reject document from pending-approval or obsolete states, indicating it does not meet acceptance criteria.
| Property | Value |
|---|
| From States | pendingApproval, obsolete |
| To State | rejected |
| Action ID | reject |
| Preconditions | Resolution field must be filled (documents rejection reason) |
| Postconditions | Signatures marked obsolete |
| Auto-Assignments | None |
| Signature Changes | ✓ Marked obsolete |
Mark as Obsolete
Purpose: Mark document as obsolete/deprecated from any active state without going through normal workflow.
| Property | Value |
|---|
| From States | Any (draft, inReview, pendingApproval, approved, published, rejected) |
| To State | obsolete |
| Action ID | markObsolete |
| Preconditions | Resolution field must be filled (documents obsolescence reason) |
| Postconditions | Signatures marked obsolete |
| Auto-Assignments | None |
| Signature Changes | ✓ Marked obsolete |
Document Workflow State Diagram
The following diagram shows all allowed state transitions and action paths:
Assignee Requirements
Document workflow actions have varying assignee requirements to ensure accountability throughout the document lifecycle:
| Action | Assignee Required | Purpose |
|---|
sendForReview | ✓ Yes | Assigns ownership for review cycle |
approve | Inherited | Must be set before reaching this state |
publish | Inherited | Must be set before reaching this state |
rework | No | Can rework without reassignment |
reject | No | Reject action independent of assignee |
markObsolete | No | Obsoletion independent of assignee |
Workflow Signature Tracking
Document workflows use formal signature-based approval with state tracking:
Signature States
| State | Meaning | Cleared By |
|---|
| Active | Signature expected and awaiting action | Approver signs or rework action |
| Approved | Approver signed with positive verdict | Manual signature by approver |
| Disapproved | Approver signed with negative verdict | Manual signature by approver |
| Obsolete | Signature invalidated by rework/reject | Automatic on rework/reject |
Automatic Approver Assignment
When document transitions to pendingApproval state (via sendForReview action in risk specification workflows), the system automatically assigns approvers using the AddDefaultSigners function:
Function: AddDefaultSigners
Parameters:
signedBy.roles = "project_approver" # Assign users with this role
signer.role = "Approver" # Label as "Approver" role
target.status.id = "approved" # Approvers can sign for this state
Result: All project_approver role members added as required signers
The project_approver role is project-specific and configured in Polarion project settings. Add users to this role to make them automatic approvers for formal approval gates.
Approval Policy Logic
The atLeastOneApprovedAndNooneDisapproved approval policy enforces these rules:
- Minimum Approval: At least one signature with “approved” verdict required
- No Disapprovals: Any single “disapproved” verdict blocks approval
- Multiple Approvers: If 3 project_approvers assigned, need 1+ approved and 0 disapproved (2 unsigned/approved is valid)
- Auto-Signature: Users with
project_approver role can auto-sign their own signature
Example approval scenarios:
| Approver 1 | Approver 2 | Approver 3 | Result |
|---|
| Approved | Unsigned | Unsigned | ✓ Passes (1 approved, 0 disapproved) |
| Approved | Approved | Unsigned | ✓ Passes (2 approved, 0 disapproved) |
| Approved | Disapproved | Unsigned | ✗ Fails (has disapproval) |
| Unsigned | Unsigned | Unsigned | ✗ Fails (no approvals) |
| Disapproved | Disapproved | Disapproved | ✗ Fails (all disapproved) |
Closure States and Resolution Field
When documents transition to closure states (approved, rejected, or obsolete), the resolution field documents the reason:
Approved Resolution
Typically brief explanation of approval rationale or signoff authority:
Example: "Approved per ISO 26262-4 Section 8.4 review gate"
Rejected Resolution
Documents reason for rejection — typically why document does not meet acceptance criteria:
Examples:
"Incomplete hazard analysis - missing operational situations"
"Failure modes not traced to safety goals"
"ASIL assignments inconsistent with severity assessment"
Obsolete Resolution
Documents reason for obsolescence — why document is no longer active:
Examples:
"Superseded by System SFMEA v2.0 (2026-02-15)"
"Subsystem design cancelled - no longer applicable"
"Replaced by integrated component FMEA"
- Risk Specification Workflow — Specialized workflow for FMEA/HARA risksheet documents with six-state lifecycle (draft → in review → approved → published)
- Work Item Lifecycle — Seven-state workflow for individual safety work items (hazards, failure modes, risk controls, requirements) with different approval gates
Integration with Standards
Document workflow states align with automotive safety compliance requirements:
| Standard | Requirement | Workflow Support |
|---|
| ISO 26262-2:2018 | Functional Safety processes require documented review and approval | Approved/Published states evidence review completion |
| ISO 26262-4:2018 | Concept phase activities require documented safety review | Rework action enables iterative HARA refinement |
| ISO 26262-5:2018 | Hardware design phase requires formal design review | Approved state gates publication for downstream design |
| AIAG-VDA FMEA 1st Ed. | FMEA analysis requires management approval | Approve action enforces formal sign-off |
| IATF 16949:2016 | Control Plan requires management review and approval | Published state serves as baseline for PPAP |
