Three settings on every Human Review node decide who sees a proposal, how long it waits, and how they hear about it. All three are per-node, so different steps in one workflow can route and notify differently.
#Routing
By default, a proposal lands in the queue for any workspace member with approval permissions: Members, Admins, and Owners. Viewers can see it but can’t decide.
To narrow that, set Assign To in the node’s Assignment section. Pin the approval to a specific team member and only that person’s queue shows it. The default is “Any workspace member.” Assignee routing isn’t plan-gated: it’s available on every plan; you just need teammates to assign to, so invite them first in Settings → Team.
Use assignment for separation of duties: route refund approvals only to someone on the billing team, contract language only to legal, and so on.
#Priority
Each node carries a priority: Low, Normal, High, or Urgent. Higher priority means faster notifications and higher placement in the queue. Urgent items float to the top and bypass quiet hours; low-priority items sort below everything else. Set priority to match real stakes so the important proposals surface first.
#Notifications
By default, reviewers are notified based on the proposal’s priority and their own preferences (below). You can override that per node by choosing explicit notification channels on the Human Review node:
| Channel | Delivery |
|---|---|
| Email (instant) | An immediate email the moment the proposal is created. |
| Email (digest) | Rolled into the reviewer’s batched digest instead of sent immediately. |
| In-app | A notification inside Rills. |
| Push | A push to the reviewer’s mobile devices. |
Selecting channels on the node overrides the default priority-based routing for that approval. Use it when a specific step always needs (or never needs) an instant ping regardless of priority.
#Personal preferences layer on top
Node channels decide what a step sends; each reviewer’s own settings decide what they receive. In Settings → Notifications, every member independently controls which priority levels trigger instant email versus push, how digests are batched (hourly, daily, weekly, or off), and their quiet hours. Urgent always breaks through quiet hours. See Notifications in Account & Workspace for the full breakdown, and the mobile app to set up push.
#Timeouts
Each Human Review node can have a timeout: default 24 hours, max 30 days. When a proposal expires unanswered, the workflow takes the timeout action you configured:
| Action | What happens on expiry |
|---|---|
| Auto-reject | The proposal is rejected and the workflow follows its failure path. The default; stale proposals shouldn’t auto-execute after the moment has passed. |
| Auto-approve | The proposal is approved as-is and the workflow continues. |
| Escalate to backup | The approval is re-routed to a workspace admin for one more round (see below). |
| Fail workflow | The run stops and is marked failed. |
Set tight timeouts for time-sensitive work (an hour for a social reply, minutes for fraud review) and longer ones for batch work that can wait.
#How escalation works
When a proposal times out on Escalate to backup, Rills creates a fresh urgent approval and assigns it to a workspace admin other than the original assignee, then waits one more round for that admin’s decision. If no eligible admin exists, or the escalated round also times out, the proposal falls back to rejected. Escalation runs once. There’s no second hop.
#Related
- Approvals : the review queue and how to approve, reject, or edit
- Modes & Confidence : approval modes, confidence scoring, and safety holds
- Batch & Task Approvals : approval types, fanout, and task steps
- Account & Workspace : team roles and personal notification preferences
- Mobile : review and push notifications on the go