Notifications

What it adds to your app

Tables notification and notification_preference. A notification centre: the Inbox page (tabs, days, read/unread, archive). NotificationBell component for any page. Settings page for email and text messages. A staff page to send a notification by hand. Workflows that email and text each notification as the person prefers.

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. Email or text each new notification, as the person prefers

   When a row changes: notification created. Then: Look up notification_preference, then Send email, then Update notification.

2. Send queued text messages through Twilio

   When a row changes: notification updated, when text_message is queued. Then: Send sms.

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.

   Param	What it is	Example
   recipient_role	The role whose people get notifications (their own table is the recipient). Optional.	member
   email_field	Optional: the email field on that role's table, for the email copy. Optional.	email
   sms_from	Optional: your Twilio phone number (E.164, like +15550100). Leave it out and texts stay off. Optional.	+15550100

3. Connect what it calls

   connect Twilio (builder, Backend, Integrations). Text messages need Twilio connected and sms_from set; email and the inbox work without them.

4. Preview, then apply to dev

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

5. 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.

Add the Notifications template (slug "notifications") 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 (recipient_role: who receives them; email_field: their email field; sms_from: twilio number).

{
  "tool": "use_template",
  "arguments": {
    "slug": "notifications",
    "project_id": "<your project id>",
    "params": {
      "recipient_role": "member",
      "email_field": "email",
      "sms_from": "+15550100"
    },
    "dry_run": true
  }
}

appbricx templates use notifications --param recipient_role=member --param email_field=email --param sms_from=+15550100 --dry-run

Works with

The services this template calls. Each page lists every action and what connecting it takes.

• TwTwilio