Workflow · Support
Reply deadline escalation
Every 30 minutes, finds rows that have sat in a waiting status (new, open, waiting on us) for longer than your deadline, stamps them escalated_at and notifies the role you choose, plus the assigned person when you name one. When a row moves back into the waiting status its clock restarts, so a second wait can escalate again.
use_template { slug: "reply-deadline-escalation" } adds
- Fields
- ‹ticket›.waiting_since, ‹ticket›.escalated_at
- Workflows
- reply-deadline-check, reply-deadline-restart
What it adds to your app
Fields waiting_since and escalated_at. A check every 30 minutes. A workflow that restarts the clock when a row waits again.
Fields added to your tables
‹ticket›.waiting_since‹ticket›.escalated_at
Workflows
reply-deadline-checkEscalate ‹ticket› rows past the reply deadline. On schedule every 30m over ‹ticket›reply-deadline-restartRestart the reply clock when a ‹ticket› waits again. On ‹ticket› updated
Where it attaches
Params point the template at your own tables and roles. Leave out the ones with defaults; a wrong one is refused with the options your app has.
| Param | What it is | Example |
|---|---|---|
ticket | The table of tickets, requests or enquiries that need a reply. Optional. | ticket |
status_field | The status enum. Optional. | status |
waiting_value | The status value that means a reply is owed. Optional. | new |
hours | How many hours a row may wait before it escalates. Optional. | 4 |
escalate_role | The role told about late rows. Optional. | lead |
assignee_ref | Optional: the ref naming who should reply, so they are told too. Optional. | assignee_id |
Use with your coding agent
- Connect the Appbricx MCP server to Claude Code, Cursor or any MCP client (quickstart).
- Paste the prompt. The agent reads the template, previews the merge with dry_run and shows you the diff.
- It applies to dev. Check it, then deploy when you are happy.
Add the Reply deadline escalation template (slug "reply-deadline-escalation") to my Appbricx project. Read it with get_template, run use_template with dry_run first and show me the diff, then apply it. Ask me where it attaches if you can't tell from my contract (ticket: tickets table; status_field: status field; waiting_value: waiting status; hours: deadline in hours; escalate_role: escalate to; assignee_ref: assigned person).{
"tool": "use_template",
"arguments": {
"slug": "reply-deadline-escalation",
"project_id": "<your project id>",
"params": {
"ticket": "ticket",
"status_field": "status",
"waiting_value": "new",
"hours": "4",
"escalate_role": "lead",
"assignee_ref": "assignee_id"
},
"dry_run": true
}
}appbricx templates use reply-deadline-escalation --param ticket=ticket --param status_field=status --param waiting_value=new --param hours=4 --param escalate_role=lead --param assignee_ref=assignee_id --dry-runGoes well with
Relay
App. Support desk with SLA timers, an email-to-ticket webhook and a lead dashboard.
customeragentleadticketmessageWelcome email
Workflow. Emails every new person a short, friendly welcome the moment they sign up.
welcome-emailSlack message on signup
Workflow. Posts to a Slack channel whenever someone new signs up, with their name and email.
slack-on-signup