Chat
The Chat block renders a live, two-sided conversation — a scrollable thread of messages between a customer and your team — inside an interface. It is a composite block pre-wired with a message composer in its Message Input slot and connects to your workspace's chat automations to load history and send replies. Messages stream in real time, older history loads as you scroll up, and message bodies render as rich HTML.
Tip: When to use Chat: Embed a customer-support conversation on a page — a running thread where your team replies. Not for AI assistants (use Copilot Chat). Not for threaded comments on records (use the comment blocks). If you only need the composer box without the thread, use Message Input.
Properties
Content
| Property | Type | Default | Description |
chatId | string (bindable) | — | The key of the conversation to show (Chat Key). Leave empty to start a new conversation; the block fills it in after the first message is sent. |
slots.messageInputPanel | slot (holds block subtree) | Container with Message Input + Attachments + Send actions | The composer docked below the thread. Pre-wired to post into the conversation. Restyle or extend the blocks inside. |
Appearance
| Property | Type | Default | Description |
layout | "BUBBLE" | BUBBLE | Message bubble styling. Fixed to Bubble — not exposed in the inspector. |
visibility | condition | — | Shows or hides the block. |
Methods
| Method | Params | Effect |
Send Message | message, attachments | Programmatically sends a message into the conversation. |
Exposed State
| State key | Type | Description |
{{ id.chatId }} | string | The active conversation's id — populated once the first message is sent for new conversations. |
Behavior & Gotchas
Note: The block writes back the chatId after the first message. For new conversations (no Chat Key set), after the first message is sent the block fills in {{ id.chatId }} with the created conversation's id. Use this to save the conversation id to your data.
Examples
Comments
The Comments block is a complete commenting experience — composer, thread, and replies — in one block. Object mode attaches the thread to a record of one of your objects and handles loading/saving automatically. Mapped mode gives you two slots (a Comment Input and a Comment List) that you wire to your own data. Both modes support rich text or plain text, @-mentions, attachments, emoji, reply threads, and top-to-bottom or bottom-to-top display.
Tip: When to use: Add discussion to a record (ticket, document, task) with zero backend work — pick Object mode, select the object and record id. Use Mapped mode when comments live in your own tables or APIs. Use the standalone Comment Input or Comment List blocks directly when you need a layout this block's two-slot arrangement can't express.
Properties
| Property | Type | Default | Description |
source | "entity" | "mapped" | entity | Object (entity) mode or Mapped (custom data source) mode. |
data | object selector | — | Object mode only. (optional) The object whose records carry the comment threads. |
assetId | string | — | Object mode only. (optional) Which record's thread to show — typically a dynamic value like the current page's record id. |
variant | "richText" | "textarea" | — | Rich text (with a formatting toolbar) or plain text composing. |
enterKeyBehavior | "START_NEWLINE" | "SEND_MESSAGE" | START_NEWLINE | What pressing Enter does while writing. START_NEWLINE: Enter adds a line; cmd/ctrl + Enter sends. |
Examples
Comment List
The Comment List block renders a thread of comments coming from your own data source. You map which fields hold each comment's id, content, timestamp, attachments, and author, and the block renders the conversation. It supports optional per-comment delete and reply actions, reply threads fetched on demand from a second source, and a configurable timestamp format. The block never stores comments itself — every add, reply, and delete raises an event for your app to persist.
Tip: When to use: Render a comment thread from any backend you own. Pair with Comment Input for the composer. Use Comments block instead when you want the whole experience pre-wired in one block.
Properties
| Property | Type | Default | Description |
data | source + field mappings | — | Comment source with field mappings: id, content, createdTime, attachments, and user details (name, profileImageUrl). |
addOns.deleteComment | toggle | — | Adds a delete action to each comment. |
addOns.replyComment | toggle | — | Adds a reply action with its own composer and a separate replies source. |
addOns.datetimeFormat | format string | — | Controls how each comment's timestamp is displayed. |
size | "sm" | "md" | md | Comment density. |
Events
| Event | Trigger |
On Delete Comment | User clicks the delete action on a comment. |
On Reply Comment | User submits a reply in the reply composer. |
Comment Input
The Comment Input block is a composer for writing comments, in either a rich text or plain text variant. It supports @-mentions of users from your own data, file attachments, an emoji picker, formatting controls, and a configurable Enter-key behavior. The block holds the draft text and attachments in its state and fires an event when the user sends — your app decides what "posting a comment" actually does.
Properties
| Property | Type | Default | Description |
variant | "richText" | "textarea" | — | Rich text (formatted, with toolbar) or plain text. |
enterKeyBehavior | "START_NEWLINE" | "SEND_MESSAGE" | START_NEWLINE | What pressing Enter does. |
extensionConfigFeatures | feature toggles | All standard on | Rich text only. (optional) Which formatting marks, lists, links, etc. are enabled. |
Events
| Event | Trigger |
On Send Comment | User submits the comment. Payload: the comment text and any attachments. |
Message Input
The Message Input block is a chat-style composer: a text box with a configurable row of action buttons — send, add attachments, emoji picker, or custom buttons. It types in Rich Text or Plain Text mode, supports voice dictation, and can be linked to a Chat block so recipient fields appear above the input. A new Message Input arrives compact and full-width with a rounded border and a pre-wired Send Message button.
Tip: When to use: Compose and send chat messages — pair with a Chat block. Collect free-form text with attachments and a submit button in one compact control. For a plain form field that submits with a form, prefer a Form block text field instead.
Properties
| Property | Type | Default | Description |
chatId | block reference (Chat only) | — | Links the composer to a Chat block. When linked, recipient fields appear above the text box. |
mode | "compact" | "default" | compact | Compact or comfortable spacing for the composer. |
variant | "richText" | "textarea" | richText | Whether the text box supports formatting. |
enterKeyBehavior | "START_NEWLINE" | "SEND_MESSAGE" | START_NEWLINE | What Enter does — new line or send. |
placeholder | string | — | Hint text shown while the box is empty. |
actions | action list | Send action | Configurable action buttons: Add Attachments, Send Message, Emoji Picker, Dictation, or custom icon buttons. |
Events
| Event | Trigger |
On Send Message | User submits the message. Payload: the message text and any attachments. |
Exposed State
| State key | Type | Description |
{{ id.value }} | string | The current text in the composer. |
{{ id.attachments }} | array | Files attached to the pending message. |
Related Blocks
| Block | Relationship |
| Copilot Chat | AI assistant transcript — use for agent conversations, not human messaging. |
| Copilot Input | The message composer for copilot conversations (vs. Message Input for human chat). |
Frequently Asked Questions
What is the Chat Key and why does it matter?
The Chat Key (chatId property on the Chat block) is a stable identifier for the conversation thread. When two users share the same Chat Key, they see each other's messages in real time. If you leave the Chat Key empty, a random ID is generated on each page load — users won't be able to continue a prior conversation. Bind it to a meaningful identifier like a case ID, ticket number, or pair of user IDs so the right people see the right thread.
When should I use Object mode versus Mapped mode in the Comments block?
Object mode is the default and easiest to set up: you provide an assetId and UnifyApps automatically stores and retrieves all comments against that asset. Use Object mode when you want comments managed entirely by the platform with no custom data layer. Mapped mode connects to your own data source, where comments are records you control. Use Mapped mode when you need to query, filter, or store comments in your own database structure, or when you need to integrate with an existing comment system.
How do I let users reply to specific comments in a Comment List?
Enable the Reply add-on on the Comment List block. This adds a reply affordance to each comment in the list. When a user clicks Reply, the Comment Input block (if present on the page) can be wired to receive the parent comment's ID via the On Reply Click event. You then pass that parent ID when submitting to your data source to maintain the thread structure.
Can the Message Input block be used independently, without a Chat block?
Yes. Message Input is a standalone composer — it fires On Send Message with the message payload regardless of whether a Chat block is present. If you don't link it to a Chat block via the chatId property, the On Send Message event still fires and you can route the message payload to any destination in your automation. The Chat block linkage is optional; it simply auto-routes the message to that chat thread.