Chat thread

Adds a chat_message table attached to one of your tables and a ChatThread component: everyone who may read the record chats on it in real time. Messages stream to the people allowed to read them (each one re-read under their access before it is sent), typing indicators and who-is-here travel over a realtime room per record that only people who can read that record may join. Your customers chat with your team when you pass a staff role, and the others in a chat are told about new messages.

View the files
Chat thread: the Chat page, added to Relay, on desktopChat thread: the Chat page, added to Relay, on a phone

What it adds to your app

Table chat_message: record, author (person or team), body, edited. ChatThread component (live messages, typing, who's here, edit, delete). A Chat page and a staff moderation list. One workflow: tell the others in a chat.

Tables

  • chat_message subject_id, author_id, staff_author_id, body, edited_at

Pages

  • /chat Chat (‹author_role›, @staff)
  • /chat-admin Chat messages (@staff)

Components

  • ChatThread A live chat on one ‹attach_to›: messages as they're sent, who is typing, who is here, edit and delete your own

Rules on every write

  • chat_message Write something before you send.
  • chat_message You send messages as yourself.
  • chat_message A message stays on its record and keeps its author.

Realtime

  • chat_message Live: each change reaches whoever can read the row
  • chat_room:<‹attach_to›> Channel. Join: signed_in (and can read the ‹attach_to›). Send: members. Shows who is here

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. Tell the others in a chat about a new message

    When a row changes: chat_message created. Then: Look up chat_message, then Notify.

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
    attach_toThe table whose records get a chat.ticket
    author_roleThe role whose people chat (their own table is the author). Optional.customer
    staff_roleOptional: a staff role that answers in the chat (its own table names who wrote). Every staff role reads and moderates chats either way. Optional.agent
    read_scopeown: the people the record belongs to (and whoever wrote in the chat); all: every person of the chatting role. Optional.own
  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 Chat thread template (slug "chat-thread") 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 (attach_to: chat on; author_role: who chats; staff_role: team that answers (optional); read_scope: who reads a chat).
MCP call
{
  "tool": "use_template",
  "arguments": {
    "slug": "chat-thread",
    "project_id": "<your project id>",
    "params": {
      "attach_to": "ticket",
      "author_role": "customer",
      "staff_role": "agent",
      "read_scope": "own"
    },
    "dry_run": true
  }
}
CLI
appbricx templates use chat-thread --param attach_to=ticket --param author_role=customer --param staff_role=agent --param read_scope=own --dry-run

Your agent adds it. Appbricx runs it.

Start freeAll templates