Approvals
Approvals add a human-in-the-loop step for sensitive actions in TinyOps. Before a high-impact change takes effect, the right people must explicitly authorize it. This prevents accidental production changes and creates an auditable decision trail.
How It Works
When an action requires approval, TinyOps creates an approval request and notifies the organization’s admins and owners via email. The approver reviews the request, optionally adds a comment, and approves or denies it. The action only executes after approval is granted.
Supported Actions
Currently, the following actions require approval:
| Action | Description |
|---|---|
enable_production_rule | Promote a rule from shadow mode to live mode |
Additional approval-required actions will be added in future releases.
Request Flow
User initiates a sensitive action
The user clicks “Promote to Live” on a rule in shadow mode.
Approval request created
TinyOps creates a pending approval request with the action details.
Admins and owners notified
All organization admins and owners receive an email notification with the request details.
Approver reviews
The approver views the request, sees the rule configuration, shadow mode statistics, and can add an optional comment.
Decision made
The approver approves or denies the request. On approval, the action executes automatically.
Approval Statuses
Each approval request progresses through these states:
| Status | Description |
|---|---|
pending | Awaiting review. No action taken yet. |
approved | Approver granted the request. Action is executing. |
denied | Approver rejected the request. No action taken. |
processing | Approval granted, action is currently being executed. |
approved_execution_failed | Approval was granted but the subsequent action failed. Can be retried. |
expired | No decision was made within 72 hours. Request is void. |
Approval requests expire after 72 hours. If the request expires, the user must submit a new request.
Safety Mechanisms
Self-Approval Prevention
A user cannot approve their own request. The approver must be a different organization member with admin or owner role.
Atomic Status Transitions
Status changes are atomic to prevent race conditions. If two admins try to approve the same request simultaneously, only one will succeed. This prevents double-execution of sensitive actions.
Execution Failure Handling
If the action fails after being approved (e.g., an API error during rule promotion), the status becomes approved_execution_failed. The request can be retried without requiring a new approval cycle.
When an execution fails after approval, check the execution logs for the specific error. Common causes include provider API timeouts and permission changes made after the request was submitted.
Configuration
Approvals are enabled at the organization level. There is no per-rule configuration needed. Any action that requires approval will automatically trigger the approval flow.
| Setting | Value |
|---|---|
| Expiry | 72 hours |
| Notified roles | Admin, Owner |
| Self-approval | Prevented |
| Retry on failure | Allowed |
Related
- Simulation Mode - rules must pass shadow mode before requesting promotion approval
- Audit Log - all approval decisions are logged
- Policies - policy promotion can trigger an approval request
- Dashboard & Analytics - approval activity appears in the activity feed