Workflow Actions

When a workflow step is assigned to you, you can take one of several actions to advance, redirect, or resolve it. The actions available depend on the step type defined in the template and your role in the project.

Where to take action

You can act on a step from two places:

1. Pending Tasks widget on the Dashboard — lists all steps assigned to you across all projects. Click the step name to open the action panel directly.
2. Instance Detail page — open the workflow instance, find the current step in the step list, and click Take Action.

Available actions

Approve

Marks the step as successfully completed with a positive outcome. The workflow advances to the next step (or closes if this is the last step).

• Available on: Approve, Review, Acknowledge, and Sign step types
• Effect: Step status becomes Completed. Approval is recorded with your name, timestamp, and any comments.
• Optional fields: Comment (free text), Attachments

Reject

Marks the step as completed with a negative outcome. The workflow's next behaviour depends on the template's rejection handling setting:

Rejection handling	What happens
continue	Workflow advances to the next step despite the rejection
stop_workflow	Workflow is cancelled immediately
return_to_previous	Workflow returns to the previous step (or to the initiator if on step 1)

• Available on: Approve step types
• Required fields: Rejection reason (free text)
• Effect: Step status becomes Completed. Rejection reason is logged.

Review with Comments

Marks the step completed while flagging that comments or issues need to be addressed. Unlike Reject, this does not trigger rejection handling — the workflow continues.

• Available on: Review step types
• Required fields: Comments (free text)
• Effect: Step status becomes Completed. Comments are permanently attached to the step record.

Return for Revision

Sends the workflow back to the initiator without rejecting it outright. Used when the document or information needs correction before the review can continue.

• Available on: Review and Approve step types
• Required fields: Reason for return (free text)
• Effect: Workflow status becomes Returned. The initiator receives a notification. The initiator can make changes and re-submit, which restarts the workflow from the beginning.

When to use Return for Revision vs Reject

Use Return for Revision when the document can be corrected and re-submitted (e.g. a drawing missing a revision stamp). Use Reject when the decision is final and no further review of this revision is expected.

Delegate

Transfers your responsibility for this step to another project member. The delegate receives a notification and the step becomes their pending task.

• Available on: All step types
• Required fields: Delegate member (search by name), optional note
• Effect: Step assignee changes to the delegate. Your assignment is removed. The delegation event is logged in the workflow timeline.
• Note: You cannot delegate to someone who lacks at least Reviewer role on the project.

Reassign (Admin only)

Permanently changes the assignee for a step. Unlike Delegate, this is an administrative override rather than a hand-off — used when the original assignee has left the project or is unavailable for an extended period.

• Available on: All step types
• Required role: Project Admin or Org Admin
• Required fields: New assignee (search by name), reason (optional)
• Effect: Step assignee is updated. Original assignee is removed. Reassignment event is logged.

Terminate (Admin only)

Force-completes a step without a meaningful action. Used only when a step is irreversibly blocked (e.g. original assignee is unavailable and no suitable delegate exists).

• Available on: All step types
• Required role: Project Admin or Org Admin
• Required fields: Reason for termination
• Effect: Step status becomes Terminated. Workflow advances to the next step. The termination and reason are permanently logged — this action is not reversible.

warning

Terminating a step bypasses the normal approval record. Use this only as a last resort and ensure the reason is documented thoroughly for audit compliance.

Parallel steps

For steps running in parallel (multiple assignees acting simultaneously), the workflow advances based on the template's completion rule:

Completion rule	When the step closes
all_must_approve	Only when every parallel assignee has acted
any_one	As soon as one assignee acts
majority	When more than half of assignees have acted

If one assignee Rejects in a parallel step and the completion rule is any_one, the rejection closes the step and triggers rejection handling immediately.

Action history

Every action is permanently recorded in the Workflow Timeline on the instance detail page. The log shows:

• Who took the action
• What action was taken
• When (exact timestamp)
• Any comments or attachments
• Any prior delegation or reassignment events

This log cannot be edited or deleted and forms the immutable audit record for the workflow run.

What's next

• Workflow Outcomes — how workflows close and what completion means
• Step Actions Reference — complete reference for all action types
• Status & Actions Reference — valid status transitions