A group is a named, project-scoped collection of org members that workflow interactions can target. When an interaction is created against a group, Mobius snapshots the current membership at that moment and routes the interaction to those members according to the group's routing policy.

The model

Each group has:

• A handle — a URL-safe identifier, unique within the project. Auto-derived from the name if omitted at creation. Immutable after creation and used to reference the group in workflow steps.
• A name and optional description — human-readable display fields.
• A routing policy — controls how an interaction collects responses from snapshotted members:
  • first_responder — the first member to claim or respond wins; the remaining snapshotted members are released. This is the default.
  • all_members — every snapshotted member must respond before the interaction is marked complete.
• Members — the live set of org members in the group.

Membership changes take effect for future interactions only; in-flight interactions use the snapshot taken at creation time. Changing the routing policy also affects only future interactions — in-flight interactions retain the policy that was snapshotted when they were created.

Routing a request to an approval team

POST /v1/projects/acme/groups
 
{
  "name": "Finance Approvers",
  "routing_policy": "all_members"
}

Mobius creates the group and auto-derives the handle from the name. When a workflow interaction targets this group, every member snapshotted at that moment must respond before the interaction completes. If the membership changes later, the updated roster applies to subsequent interactions — existing in-flight interactions are unaffected.

Where you see it

• Dashboard — Projects → <project> → Groups lists each group with its handle, routing policy badge, and live member count. Expanding a row shows the current member list and lets you add or remove members.
• API — the Groups tag covers creating, listing, updating, and deleting groups, plus managing members.

See also

• Interactions — the step kind that targets groups.
• Workflows — the definitions that contain interaction steps.
• Runs — the executions in which group-targeted interactions resolve.