Source file: riskSpecification-workflow.xml
Workflow States
Status Definitions
| Status | ID | Description | Editability |
|---|
| Draft | draft | Initial status for all new documents. All TARA analysis work happens here. | Fully editable |
| In Review | inReview | Document is under review. Approvers have been notified and are evaluating the TARA content. | Read-only (pending signatures) |
| Approved | approved | At least one project_approver has provided an electronic signature. Content is validated. | Read-only |
| Published | published | Finalized baseline. The document is a controlled artifact for audit purposes. | Read-only (locked) |
Workflow Actions
Send for Review
Transitions a Risk Specification from Draft to In Review.
| Property | Value |
|---|
| Source status | draft |
| Target status | inReview |
| Automated function | AddDefaultSigners |
| Signer role | project_approver |
| Target approval status | approved |
Behavior: When triggered, the AddDefaultSigners function automatically populates the document signature request with all users holding the project_approver Polarion role. No manual signer selection is required.
The approver list is determined by role membership, not manually curated per document. Changes to project_approver role membership automatically affect who must sign Risk Specifications.
Approve
Transitions a Risk Specification from In Review to Approved after signature validation.
| Property | Value |
|---|
| Source status | inReview |
| Target status | approved |
| Signature policy | atLeastOne |
| Auto-signature | project_approver |
Behavior: Uses Polarion’s electronic signature mechanism. The atLeastOne policy means a single signature from any project_approver role holder is sufficient to advance the document. Unanimous approval is not required.
The default policy requires only one approver signature (1-of-N). Teams requiring unanimous approval must change the signature-policy to all in the workflow configuration.
Publish
Transitions a Risk Specification from Approved to Published.
| Property | Value |
|---|
| Source status | approved |
| Target status | published |
| Functions | (none) |
| Signatures | (none required) |
Behavior: Publishing is a separate step from approval. This allows approved documents to be staged before official release, useful in programs with coordinated release cycles. No additional signatures or functions are triggered.
Rework
Returns a Risk Specification from any non-Draft status back to Draft.
| Property | Value |
|---|
| Source status | inReview, approved, or published |
| Target status | draft |
| Function 1 | MarkWorkflowSignaturesAsObsolete |
| Function 2 | ResetSignaturesVerdict |
Behavior: The rework action simultaneously:
- Marks all existing workflow signatures as obsolete — prevents previously collected approvals from being reused on modified content
- Resets the signature verdict — the document’s approval status displays as “pending” rather than showing the previous verdict
Rework invalidates ALL prior signatures. The full Send for Review, Approve, Publish cycle must be repeated after any rework. This is a critical ISO/SAE 21434 audit trail requirement — the re-approved document must reflect the actually reviewed content.
Workflow Functions
| Function | Triggered By | Effect |
|---|
AddDefaultSigners | Send for Review | Adds all project_approver role holders as required signers |
MarkWorkflowSignaturesAsObsolete | Rework | Marks all existing signatures as obsolete |
ResetSignaturesVerdict | Rework | Clears the approval verdict state |
Prerequisites
| Requirement | Details |
|---|
project_approver role | Must be assigned to at least one user in the Polarion project for the approval workflow to function |
| Module type | This workflow applies to Polarion LiveDoc modules (documents), not individual work items (prototype=Module) |
Integration with Dashboards
The workflow status is displayed in multiple locations:
| Dashboard | Display |
|---|
| Risks Home | Status column in system element navigator |
| TARA Summary Report | (indirect — document status not shown, but edits while in Draft change verdict counts) |
Common Workflow Scenarios
Normal Progression
Error Discovered After Approval
Reviewer Requests Changes
There is no separate “Reject” or “Request Changes” action from the In Review status. Reviewers who want changes must use the Rework action (which returns to Draft) or communicate feedback out-of-band.
Related Pages
Source: .polarion/documents/workflow/riskSpecification-workflow.xml