Overdue alerts

A daily check over any table with a due date and a status: tasks, jobs, invoices, orders. A row whose due date has passed and isn't done gets an overdue_since stamp, the assigned person gets a notification (when you name an assignee field), and the role you choose gets one notification listing everything overdue. Marking a row done clears the stamp.

Overdue alerts: its 2 workflows, trigger to steps

What it adds to your app

Field overdue_since on your table. A daily 09:00 check that stamps and announces overdue rows. A workflow that clears the stamp when a row is done.

Fields added to your tables

  • ‹entity›.overdue_since

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. Flag and announce overdue ‹entity› rows

    On a schedule: schedule daily 09:00 over ‹entity›. Then: Look up ‹entity›, then Update ‹entity›, then Notify.

  2. Clear the overdue flag when a ‹entity› is done

    When a row changes: ‹entity› updated, when ‹status_field› is ‹done_value›. Then: Update ‹entity›.

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
    entityThe table of things that can be late (tasks, jobs, invoices). Optional.task
    due_fieldThe date or timestamp field holding when it is due. Optional.due_on
    status_fieldThe enum field that says whether it is finished. Optional.status
    done_valueThe status value that means finished (never overdue). Optional.done
    assignee_refOptional: the ref field naming the person responsible, so they are told directly. Leave it out to tell only the team. Optional.assignee_id
    notify_roleThe role that gets the daily list of overdue rows. Optional.staff
  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 Overdue alerts template (slug "overdue-alerts") 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 (entity: table with due dates; due_field: due date field; status_field: status field; done_value: done value; assignee_ref: assigned person; notify_role: team to tell).
MCP call
{
  "tool": "use_template",
  "arguments": {
    "slug": "overdue-alerts",
    "project_id": "<your project id>",
    "params": {
      "entity": "task",
      "due_field": "due_on",
      "status_field": "status",
      "done_value": "done",
      "assignee_ref": "assignee_id",
      "notify_role": "staff"
    },
    "dry_run": true
  }
}
CLI
appbricx templates use overdue-alerts --param entity=task --param due_field=due_on --param status_field=status --param done_value=done --param assignee_ref=assignee_id --param notify_role=staff --dry-run

Your agent adds it. Appbricx runs it.