The Inbox

One shared queue for every message your customers send you, whatever way they sent it. Email that arrives at a mailbox address, chats from the widget on your site, and form submissions all become tickets — and a ticket is an ordinary record, so everything you can already do with records still applies to it. The Inbox is the place you work them: see what is waiting, answer it, assign it, and move it along. What lands here A table appears in the Inbox as soon as anything has written to it — you do not switch the Inbox on. Run a help desk, from the + New menu, sets the routes up for you. You can also wire any of them by hand, and conversations start arriving either way: • Email in — forward your support address at a RowFold mailbox and every email becomes a ticket, with replies threaded onto the original rather than piling up as new rows. • Chat widget — visitors write from your site and you answer here. • Public forms — each submission opens a conversation. If several tables receive messages, chips above the list let you narrow to one. Reading the queue Conversations are ordered by most recent activity. A warm line down the left and a bolder name mean the customer spoke last — nobody has answered yet. Use Needs reply to see only those. An internal note deliberately does not clear that state: writing a note to your team is not the same as answering the customer, and the queue would be lying if it said otherwise. Notes are prefixed Note: in the preview so an internal remark is never mistaken for something the customer was told. An email to anybody other than the customer doesn't clear it either. The reply box can email anyone, so a message to a supplier about the customer's order lands on the ticket too, and the customer is still waiting. Its preview starts To and the address it went to. Where the queue promises a response time, each conversation also carries the clock: a countdown chip while there is time, Held while the clock waits on the customer, Late once a promise is missed. A Late filter appears beside Needs reply on exactly those queues. Response times explains how the promises work. Every tab searches the whole queue, not only what is on screen, so a late ticket nobody has touched in weeks is still under Late. The list shows sixty conversations at a time. Show more at the bottom reaches older ones, up to six hundred; past that the list says so, and a tab or a table chip narrows it. Answering The middle pane is the same conversation and the same composer you get at the bottom of the record page. Reply to customer reaches them the way they reached you — email if the ticket came by email, the chat window if they are still there, and both if they left an address. Internal note is never sent anywhere. Every message carries a badge saying what actually happened: Sent to customer, Delivered in chat, Internal note · not sent, or Not delivered with the reason. An email to anyone else, a supplier say, is badged Sent to and the address, and it doesn't count as answering the customer. Press ⌘/Ctrl+Enter to send. When a teammate has the same conversation open, the thread says so, and shows typing dots while they write, so two people stop answering one customer at once. This is for your side only; visitors never see who is viewing or typing. Saved replies Anything your team answers twice belongs in a saved reply. Press the Saved replies button, or type / in an empty composer, and pick one — it drops into the box so you can edit it before sending. Bodies can carry the same tokens automations use, like {{record.name}} or {{workspace.name}}. They are filled in against the ticket you are answering, and you always see the finished text before it goes anywhere. A reply can also move the ticket. Give a saved reply Also set status to and Also assign to — Whoever sends it, a named teammate, or Clear the owner — and both happen when the reply is sent, not when it drops into the composer. Edit the text as much as you like first; the actions ride the send. Assignment and status Both are ordinary fields on the ticket, which is why they show up everywhere else too — in views, filters, reports and automations. The Inbox uses a People field for the owner. It picks one named something like Assignee or Owner, or the only People field if there is just one. If the table has none, Admins get a one-click Add an Assignee field button — the Inbox never adds a column to your table on its own. For status it uses the Select field the chat widget or the mailbox nominates, or one named Status. Changing it here is an ordinary edit: it is audited, it can trigger automations, and if the widget publishes that option to visitors, the customer sees the ticket move. Staying current The queue and the open conversation both update on their own. A live connection makes that near-instant, and a slower poll runs regardless of whether that connection is healthy — because the failure worth designing against is an agent reading a ticket, believing they have seen everything, while the customer's reply sits unrendered. Updates pause while the tab is in the background and catch up the moment you return. Tips • Notifications about new messages open the conversation straight in the Inbox; the full record is one click further, under Open record. • The right-hand pane is the customer's record — their details and anything linked to them — so you rarely need to leave the queue to answer well. • Mine is the default view once anything is assigned to you; otherwise the Inbox opens on All so it is never mysteriously empty. • A chat visitor can leave an email address mid-conversation. When they do, it fills the reply box automatically, so an answer written after they close the tab still reaches them. Good to know • An internal note does not clear Needs reply. That is deliberate — the customer is still waiting. • A reply answers the customer only when it goes to an address the ticket has for them: the one they gave in chat, the one their email came from, or the email field your mailbox or chat widget fills in. If a customer asks to be answered at a new address, put it in that email field before you reply, or the reply is treated like an email to a supplier and the conversation stays in Needs reply. • If a table has two People fields and neither is named for the job, the Inbox will not guess which one means owner; rename one to Assignee. • Mine means tickets whose owner field names you as a person, not your name typed as text. A ticket assigned to two people is in both of their Mine tabs. An owner typed as plain text belongs to nobody, so that ticket shows under neither Mine nor Unassigned; pick the person instead. • Status only appears when a Select field has been nominated on the widget or the mailbox, or is named Status. An arbitrary Select is not adopted, because a chip showing Priority as though it were status is worse than no chip. • A reply needs somewhere to go: an email address plus a mailbox, or a chat that is still open. With neither, the composer says so rather than quietly saving a message nobody receives. Who can do what • Any workspace member can open the Inbox; you only ever see conversations on tables you already have access to. • Replying takes the same permission as editing the record, so a Viewer reads the thread but gets no composer. • Assignment and status follow field permissions — a field you may not edit shows as a disabled control rather than failing when you use it. • Only Admins can add an Assignee field, because adding a column is a change to the table's schema.