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.
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_messagesubject_id, author_id, staff_author_id, body, edited_at
Pages
/chatChat (‹author_role›, @staff)/chat-adminChat messages (@staff)
Components
ChatThreadA 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_messageWrite something before you send.chat_messageYou send messages as yourself.chat_messageA message stays on its record and keeps its author.
Realtime
chat_messageLive: each change reaches whoever can read the rowchat_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.
- 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.
- Pick the project
Use the button above, or ask your coding agent with the Appbricx MCP server connected (quickstart).
- 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 attach_toThe table whose records get a chat. ticketauthor_roleThe role whose people chat (their own table is the author). Optional. customerstaff_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. agentread_scopeown: the people the record belongs to (and whoever wrote in the chat); all: every person of the chatting role. Optional. own - Preview, then apply to dev
A dry run shows the diff and the check report; applying it changes your dev environment only.
- 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 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).{
"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
}
}appbricx templates use chat-thread --param attach_to=ticket --param author_role=customer --param staff_role=agent --param read_scope=own --dry-runGoes well with
Huddle
Realtime team chat: public and private channels, live messages, typing indicators, who's online, unread counts and @mentions.
Margin
Live document review: comments in the margin, replies, reactions and resolve, who's viewing, and edits that appear for every reader as they're saved.
Corkboard
Multiplayer sticky-note board for retros and planning: notes you add, edit, drag between lanes and vote on, live for everyone, with who's on the board and who's editing which note.