Support/First Class Modules/Conversations & messages

First Class Modules

Conversations & messages

Provides native channel threads with participants, messages, status, priority, internal notes, outbound replies, related context, activity, dynamic fields, and favorites.

Runtime key
module.conversations
Experience
Customer & team communication
Security
Server-enforced

Use Conversations for durable communication history across internal, email, SMS, form-driven, and other supported channels while Universal Inbox points people to the threads that need attention.

Note

The bundled renderer key is module.conversations. First-class means BuildWithHQ supplies a native, typed, secured runtime experience inside normal app provisioning and the signed-in user's existing permissions.

What it does

Provides native channel threads with participants, messages, status, priority, internal notes, outbound replies, related context, activity, dynamic fields, and favorites.

Key capabilities

  • Search and filter conversation threads by status.
  • Create internal conversations and manage subject, priority, and lifecycle.
  • Read escaped message history and post internal notes or permitted outbound replies.
  • Expose unread/favorite state, dynamic fields, related records, and activity.

Common uses

  • Customer support and success communication.
  • Project, sales, case, and operations correspondence.
  • The native thread behind Universal Inbox triage and governed AI suggestions.

How it connects

Inbound providers normalize into native Conversations and messages, then create or update Inbox attention. Threads can relate to Contacts, orders, projects, Work Orders, Files, and any authorized record without making Inbox the source of truth.

Where applicable, its records use the universal RecordId conventions so they can participate in secured relationships, activity history, favorites, dynamic fields, notifications, Inbox attention, and global search without copying the source record.

Security and data boundary

Conversation, message, channel, DataRole, and location access is enforced server-side. Outbound capability and edit rights are explicit; provider credentials and direct channel endpoints never reach the browser.

  • The authenticated service derives the SaaS app, tenant account, user, DataRole, and location scope; browser identifiers are never authorization proof.
  • The page editor composes React components with validated data bindings. Those bindings call typed runtime APIs, whose application services execute reviewed stored procedures.
  • List, search, detail, relation, activity, favorite, and write operations reapply their required server-side permissions.

Add it to an app

  1. Open the SaaS app in the Developer Console and identify the user journey and page where this module belongs.
  2. Add the validated module.conversations module block through the supported page/template authoring flow.
  3. Configure the module with the page editor's React components and validated data bindings; the bindings call authenticated platform APIs backed by reviewed stored procedures.
  4. Place the page in the correct user-type menus and assign existing DataRole, record, field, and location permissions.
  5. Test list, detail, search, empty, denied, stale-update, and cross-location behavior before publishing an exact version.
Tip

Use one canonical thread per real conversation and relate it to business context. Avoid copying message bodies into custom records or building a second inbox table family.

Important

A renderer being bundled in the tenant application does not make its data visible in every app. The server returns only components and records authorized for the current app and signed-in user; unavailable or unauthorized blocks fail closed.