Task Overview
Tasks are the human-action steps inside a promotion workflow. Every promotion (moving a model from one environment to another) runs through the singlestandard_promotion workflow executed by the Tower Sidecar, which produces tasks for the appropriate group at each step.
A typical promotion produces:
- An Approve task — assigned to the
tower-approversgroup. The reviewer chooses one ofAPPROVED,REJECTED, orREQUEST_CHANGES. - A ChangeRequest task (only if the reviewer chose
REQUEST_CHANGES) — handed back to the original submitter, who can either resubmit (returning the promotion to review) or cancel it.
Promotion lifecycle
The promotion that owns a task moves through a known state machine. Tasks only exist while the promotion is inACTIVATED or IN_REVIEW.
Task properties
Each task exposes:Viewing Tasks
Task List
The Tasks view shows all tasks assigned to your role:- Filter by status (Open, Completed, All)
- Sort by date or priority
- Search by model name
- Group by type
Task Details
Click a task to see full details:- Model version information
- Request justification
- Audit history
- Related tasks
Actioning Tasks
Approve Task
- Review the model and request details
- Click “Approve”
- Add required comment
- Confirm action
Reject Task
- Review the model and request details
- Click “Reject”
- Add required comment explaining rejection
- Confirm action
Review and Request-Changes Flow
Aletyx Decision Control Tower promotions run thestandard_promotion workflow, which separates the review role from the requester:
- Approve task: assigned to the
tower-approversgroup. The reviewer choosesAPPROVED,REJECTED, orREQUEST_CHANGES. - ChangeRequest task: when the reviewer requests changes, the task is handed back to the original requester, who can resubmit (returning to review) or cancel the promotion.
- Audit: every action — submit, approve, reject, request changes, resubmit, cancel — is recorded in the audit trail.
- Sarah (Business Analyst) submits a model for promotion
- The Approve task appears for the
tower-approversgroup - Tom (an approver) reviews and either approves, rejects, or requests changes
- If Tom requests changes, the ChangeRequest task returns to Sarah to resubmit or cancel
Task Workflow
Role-based task assignment
Tasks are assigned to OIDC role groups; whoever holds the matching app role in the configured provider can claim and act on them. Aletyx Decision Control Tower uses two roles:
Group membership is configured in the OIDC provider (see Identity & Access Management). Tower compares the role claim in the JWT literally to the role names above, so the claim or group-mapping in the provider must produce exactly
user or tower-approvers.
Task History
All task actions are recorded in the audit trail:- Who performed the action
- When it was performed
- What action was taken
- Comments provided
Metrics
Aletyx Decision Control Tower exposes Micrometer counters via the standard Spring Boot Actuator (/actuator/prometheus):
Combine with the per-deployment
process_instances_* metrics emitted by the Tower Sidecar to derive higher-level views like approval lead time or rejection rate in your observability stack.
Troubleshooting
Task Not Appearing
- Verify you have the correct role
- Check task is still open
- Refresh the view
- Clear browser cache
Cannot Approve
- Verify you are a member of the
tower-approversgroup - Confirm the task is still open (not already actioned)
- Ensure all required fields are completed
- Check session hasn’t expired
Deployment Failed
- Check target environment health
- Verify database connectivity
- Review deployment logs
- Contact administrator
Next Steps
- Environment Management: Understanding environments
- Portal Tour: Tour of the Aletyx Decision Control Tower interface
- Governance Tasks (how-to): Claim, approve, reject, and request changes