Model the request
Define the request — type, requester, details, status — once. Storage and queries come from that definition.
Approval and request desks
Turn scattered request handling — email threads, chat pings, spreadsheets — into a structured application with states, assignments, and audit.
For: Internal platform and operations teams · Example concept
The problem
Requests arrive everywhere and are tracked nowhere. Approvers lack context, requesters lack visibility, and nobody can answer "where is it?" without asking around.
What it produces
- Every request has a visible state and owner
- Decisions are recorded with full context attached
- Approval policy lives in inspectable automations everyone can see
data: request
| id | type | requester | state |
|---|---|---|---|
| REQ-1042 | Equipment | a.okafor | in_review |
| REQ-1041 | Access | m.silva | approved |
| REQ-1039 | Travel | j.larsen | draft |
- 1 Validate request
- 2 Route to approver
- 3 Record decision
- 4 Notify requester
automation · resumable · schedulable
Request inbox
Request detail
Approval form
screens · connected to data and automations
How it comes together
Compose the desk
List views with filters, a detail view with full context, and action buttons wired to approval automations give each role the screen it needs.
Automate the path
An automation validates, routes to the right approver, records the decision, and notifies the requester. Escalation is just another automation — never another inbox.
The pieces involved
- Request and decision data models
- Inbox, detail, and review screens
- Routing, approval, and notification automations
- Scheduled escalation and digest jobs
Other concepts
Is this your problem?
Waitlist teams will help shape which application concepts we prove first.
Join waitlist