> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Group messaging versus labeling — shared threads versus named claims

> When to reach a collection of recipients with one group flow, versus when to thread one recipient and tag it with a label — with the platform's routing claim (sender election) model that decides who owns a work item.

# 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](https://orbit.devotel.io/glossary/group-messaging): 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](/channels/mms) 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](/api-reference/endpoints/inbox) 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

| I need to...                                                   | Use                                 | Why                                                             |
| -------------------------------------------------------------- | ----------------------------------- | --------------------------------------------------------------- |
| Reach a collection of 2–20 recipients with MMS in one call     | Group flow — `POST /messages/group` | Fan-out is the only group primitive carriers expose             |
| Thread an inbound reply to one owner                           | Routing claim                       | Only one claim can own a work item at a time                    |
| Annotate a conversation for reporting or QA                    | Label                               | A label is static; it does not touch the ownership              |
| Broadcast a marketing send to many recipients at once          | Campaign or batch, not group        | Group semantics are per-recipient receipts, not a living thread |
| Reach 3+ recipients as a shared conversation on a rich channel | Inbox thread                        | Rich clients keep one conversation object for group chat        |

Cross-links that make the choice concrete: the [Group Messaging glossary entry](https://orbit.devotel.io/glossary/group-messaging) fixes the name; the [MMS channel group flow](/channels/mms) carries carrier-level fan-out receipts; the [inbox setup guide](/guides/inbox-setup) runs claim assignment through digital queues; and [cascade failover groups](/concepts/message-cascade-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](/compare/best) is where the Group Messaging term landed first.