Websites had their WordPress moment. SaaS is having its BuildWithHQ moment. See the new BuildWithHQ homepage →
Home/Platform/Universal inbox
Universal inbox

One inbox for every channel, governed like every other record

Email, SMS and MMS, inbound web leads, and internal user-to-user messages all land in the same conversation model. That is not a convenience feature. Because every conversation is a first-class platform record, it inherits the entire security model without a single line of inbox-specific permission code.

Every channel, one model

What lands here

Read the inbox guide

Email

Inbound mail is parsed and mapped onto the record it belongs to, and outbound mail queues through the same transactional layer.

SMS and MMS

Text conversations appear as threads alongside everything else rather than in a separate tool nobody checks.

Inbound web leads

Form submissions from your site arrive as conversations attached to a contact, not as an email nobody owns.

Internal messages

User-to-user direct messages live in the same place, so a handover does not require a second application.

Routing

Three ways a line can be owned

The routing model is deliberately small, because inbox routing is where most systems accumulate special cases.

Personal lines

Owned by one user. Their email address, their direct number, their messages.

Role-routed lines

Owned by a role rather than a person, so support@ or dispatch@ reaches whoever currently holds that role instead of whoever set it up.

Shared lines

Owned by neither, visible to everyone permitted to see the records they attach to.

Agent-managed lines

A personal line can be routed to that user's AI agent, which drafts and queues responses for approval rather than sending unattended.

Why the record model matters

The part that is easy to miss

This is the design decision that pays off repeatedly.

Every conversation is bound to the universal record layer. That single choice means conversations automatically get:

  • The same permissions. Who can read a conversation is answered by the same function that answers who can read an invoice. There is no inbox-specific security code to get wrong.
  • Location scoping. A regional manager sees their region's conversations, without that rule being implemented twice.
  • Custom fields. Add fields to conversations the same way you add them to anything else.
  • Relationships. Link a thread to a deal, a ticket, a task, and a contact without duplicating it.
  • Access logging. Reads of a conversation are recorded like reads of anything else, which matters when the conversation contains something sensitive.

Notifications surface a count of items awaiting review, so the inbox is something people act on rather than something they discover late.

Common questions

Questions about this

Do I need a separate helpdesk product?

For most cases, no. Conversations, assignment, follow-up, and reporting are part of the platform, and the support-desk build guide walks through a complete example.

Can a conversation be private to one user?

Yes. Personal lines are owned by a user, and normal record permissions apply to everything else.

Is inbox data included in exports?

Yes. Conversations are records, so they export with everything else, including attachments.

Get started

Build it, then prove what it did

Create an account, explore the full builder console, and launch your first application on a custom domain. Nothing is charged while your application is still in development.

Start building today

No credit card required. The console preview, the documentation, and the architecture reference are all readable before you sign up.

Get started free Read the docs