message.comDevelopers

Department vs team

Department and team mean the same thing across the support-software industry: a named group of agents you can route conversations to. message.com calls them departments in the product UI and groups in the database schema.

Definition

A department is a routing target. It bundles agents who share a function (Sales, Support, Billing, Onboarding) so conversations can land on the right cluster of people without addressing a specific individual. When a conversation is assigned to a department instead of an agent, any qualified agent in that department can claim it.

Some vendors call this a "team", others call it a "group", others call it a "queue". The functional model is the same. message.com uses "department" in customer-facing copy because it matches how organizations describe themselves.

Routing model

Three things determine where a conversation lands:

  1. Channel. A phone call cannot route to an agent without channels: ["calls"].
  2. Department. Filters agents by membership in the conversation's groupId.
  3. Availability. Only agents marked available receive routed conversations.

The intersection of those three is the eligible-agent pool. Within that pool, message.com round-robins (or least-busy, depending on settings) to pick the actual assignee.

Agent membership

Agents belong to one or more departments through a many-to-many join. An agent can be both Sales and Support. A supervisor can manage one department but answer in another. The Departments API exposes membership through POST /departments/:id/members.

Supervisor scope

Supervisors see only conversations and reports for their own departments. This is the RBAC mechanism that lets you grow past five agents without giving everyone access to every customer. Admins see everything. Agents see their own work.

Department transfer

A conversation can be transferred to a different department mid-thread. Transfer is instant (no 30-second handshake the way agent-to-agent transfers work) because the receiver is a pool, not a person. The transfer is logged in audit log.

Why the schema says groups

Early development used "group" in code and only later settled on "department" for the UI. We did not rename the database column because doing so would invalidate every customer's saved views and reports. The API mirrors the schema and exposes groupId on conversations. Treat groupIdand "department ID" as synonyms.