Group messaging model and routing claim election
There are two ways to reach a collection and one way to assign work. On the outbound side a group flow sends one payload to many recipients in a single operation. On the inbound side a routing claim — what operators colloquially call a “label” — marks one conversation as belonging to one disposition lifecycle, so a conversation lives in exactly one queue state at a time. This page aims to keep both models honest: a group flow is a fan-out, not a living thread; a routing claim is a commitment, not a tag. The split exists because carrier protocols treat the two patterns differently. SMS and MMS have no shared conversation object, so group is a fan-out of per-recipient copies; voice rings have one claim at a time, so a routing claim binds one work item to one owner. Conflating them — treating a group send as if it were a thread, or treating a label as if it were routing — is how most workflow design errors originate.Group flow: fan-out, not a thread
“Group Messaging” on this platform means the capability documented in the Group Messaging glossary entry: a text conversation logically shared among three or more recipients, where every member receives each message in the thread. The docs settled on this name — as the newer commit chain moved it into the glossary and wired channel parity — because group semantics cannot live on top of one-to-one sends, and the unqualified “label” vocabulary in onboarding was claiming thread behavior the carrier does not hold. Carrier reality, however, is that SMS and MMS cannot hold a joint thread. Group SMS is delivered as a fan-out — one copy per recipient — and MMS group mode likewise fans out one payload to up to twenty recipients in a single call.POST /api/v1/messages/group on the MMS channel is the platform’s group-MMS surface: every recipient is pre-inserted as a pending row, each per-recipient send carries its own idempotency key within the group, and per-recipient status is returned in the same response. If you need a true conversation object on a rich channel, use the platform’s inbox surface rather than a group send; if you need per-recipient receipts on SMS or MMS, use the group flow. What you must not do is treat a group send as if it were a living thread.
Where you elect to receive the return path, apply the same rule. The unified inbox maintains conversational threads with their participants; SMS campaigns, batch, and group flows carry the fan-out copies. Outbound still exits over the Devotel wholesale softswitch — the group choice never changes where traffic terminates.
Sender election: how a shared thread is answered
A group flow answers “which recipients see this,” not “who will reply.” A returning message — or an inbound voice call — has to go to exactly one owner. The platform resolves that ownership with routing claim election: the claim module never runs two competing claims on one conversation at the same time. For the inbox the claim is a conversation-level assignment through the digital queues: dispatch checks agent presence, reads the capacity ledger, and claims the item on the winning agent’s connection — the losing replicas never observe a second claim. For voice rings the claim elects among ring-group members by strategy — first-available, round-robin, or fewest-calls — and the group is again a single claim. Configuring either surface as if a label were an idempotent tag is incorrect: a label is static annotation on already-assigned work, and a claim is a single-owner routing decision.Labels versus routing claims
On the work-item lifecycle, a label marks static metadata on a conversation (a tag that routing, reporting, or QA can read), whereas a routing claim holds a terminal or mid-lifecycle commitment on the same conversation. You pick a label-style response when the response does not change who owns the item; you pick a claim when it must exclude every other claim. The disposition lifecycle under the Inbox API reference governs the claim states — open, pending, resolved — and a label applied to a sealed item mutates the annotation, never the lifecycle. Refer to that lifecycle before treating any label as routing truth.Choosing between them
Cross-links that make the choice concrete: the Group Messaging glossary entry fixes the name; the MMS channel group flow carries carrier-level fan-out receipts; the inbox setup guide runs claim assignment through digital queues; and cascade failover groups bind every fallback hop of a send into one logical group — a group of legs within a single send, not a group of recipients. For the marketplace context that motivated the glossary entry, the buyer’s-guide lane under Orbit vs alternatives is where the Group Messaging term landed first.