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.

View the files
Reply deadline escalation: its 2 workflows, trigger to steps

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

How its workflows run

Each one is a server workflow in your project: it runs on its trigger, with retries, and its runs show in the builder's log.

  1. Escalate ‹ticket› rows past the reply deadline

    On a schedule: schedule every 30m over ‹ticket›. Then: Look up ‹ticket›, then Update ‹ticket›, then Notify.

  2. Restart the reply clock when a ‹ticket› waits again

    When a row changes: ‹ticket› updated, when ‹status_field› is ‹waiting_value›. Then: Update ‹ticket›.

Set it up

It merges into the contract of an app you already have. Nothing is overwritten: a name you already use is refused until you pass a prefix.

  1. Pick the project

    Use the button above, or ask your coding agent with the Appbricx MCP server connected (quickstart).

  2. Point it at your tables and roles

    Leave out the ones with defaults; a wrong one is refused with the options your app has.

    ParamWhat it isExample
    ticketThe table of tickets, requests or enquiries that need a reply. Optional.ticket
    status_fieldThe status enum. Optional.status
    waiting_valueThe status value that means a reply is owed. Optional.new
    hoursHow many hours a row may wait before it escalates. Optional.4
    escalate_roleThe role told about late rows. Optional.lead
    assignee_refOptional: the ref naming who should reply, so they are told too. Optional.assignee_id
  3. Preview, then apply to dev

    A dry run shows the diff and the check report; applying it changes your dev environment only.

  4. Deploy

    When dev looks right, deploy. Production gets a snapshot first, so you can roll back.

Use it with your coding agent

The agent reads the template, runs a dry run, shows you the diff and applies it.

Prompt
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).
MCP call
{
  "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
  }
}
CLI
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-run

Your agent adds it. Appbricx runs it.

Start freeAll templates