Channel workstreams and how channels attach

What it does

A workstream is the container a channel instance plugs into. It holds the channel binding, the work distribution settings, the capacity model, the session and notification templates, and the routing rulesets for anything arriving on that channel. No workstream, no channel — you cannot configure chat, SMS or social without one.

Key facts

Three workstream types: Messaging (chat, SMS, social, Teams), Record (case, email, activity and other routable tables) and Voice. Voice is a Contact Center concern; the other two are what a Customer Service project configures.
Channel types selectable on a messaging workstream: Chat, Facebook, LINE, WhatsApp, Microsoft Teams, SMS (Azure Communication Services), SMS (Twilio), and Custom messaging channel.
Work distribution mode is Push or Pick, and it cannot be changed after the workstream is created. Get this wrong and you rebuild the workstream. Voice supports push only.
Capacity is either Unit based or Profile based, chosen per workstream. Both need to be set up by an administrator first, and mixing models across workstreams that share representatives is where capacity maths stops making sense.
Block capacity for wrap up has three options: Always block (the default), Don't block, and a custom time between 30 seconds and 60 minutes. If the capacity profile uses End of Day mode, capacity is not reset when the custom duration expires.
Allowed presences decides which presence statuses can be handed work. Leaving Inactive and Do not disturb selected is how representatives end up with work items they never see.
Auto-close after inactivity is available for persistent chat, SMS, social and Microsoft Teams — the asynchronous channels, in other words. It does not apply to ordinary live chat.
Representative affinity is on by default for persistent chat, SMS, social and Teams: when a waiting conversation goes active it goes back to the same person regardless of capacity or presence. It only applies to push distribution, and it is overridden if the notification template has auto-assign set to No.
Advanced settings on a workstream: session templates, representative notification templates (incoming unauthenticated, incoming authenticated, consult, transfer, supervisor assign, and returning conversation for persistent chat), context variables, smart assist agents, quick replies, and the live conversation counter.
Quotas that bite: 200 route-to-queue rules per workstream, 10 classification rulesets with 100 rules each, 100 intake rules for records. Configuration changes take up to 15 minutes to propagate.

When to use / skip

There is no skipping this — if you are doing any channel work in Customer Service, you are doing workstreams. The real question is how many. The instinct is one workstream per channel, which is fine for a first release, but it is the wrong default once volume arrives, because the workstream is also where session behaviour, capacity and notification templates live. If chat from the retail site and chat from the trade portal need different session tabs, different capacity weight or different notification timeouts, they need different workstreams even though they are the same channel type.

Conversely, resist one workstream per queue. Routing to queues is what route-to-queue rules are for, and 200 of them per workstream is plenty of headroom. Proliferating workstreams multiplies the config you have to keep in sync and makes reporting messier.

Configuration decisions

Push or pick, per workstream, decided before you press save because it is a one-way door.
Unit-based or profile-based capacity, and whether the same model is used across every workstream the same people work in.
Wrap-up blocking: always block, don't block, or a custom window — and what that implies for concurrency targets in the SLA conversation.
Which presences are allowed work, and whether representatives can pull work while on a break status.
How many workstreams per channel, driven by session template and capacity differences rather than by routing.
Whether a Copilot Studio agent is attached, and whether that workstream is push-based (agents only receive conversations on push workstreams).

Gotchas

Work distribution mode is immutable. Copy the workstream if you need to switch, then repoint the channel and rebuild the rules — there is a Copy action which at least brings the rules with it.
The fallback queue is real and it will catch traffic. When no route-to-queue rule matches, work lands there, and if nobody has been added to that queue it just sits. Adding users to the queue is a separate step after creating the workstream.
Representative affinity quietly overrides capacity. A representative at full load can still receive a returning SMS conversation, which makes concurrency figures look wrong until you remember why.
Auto-close after inactivity is per workstream and asynchronous-only. Clients who expect abandoned live chats to close themselves are thinking of a different setting.
Configuring a workstream needs system administrator rights or explicit permissions on secure columns; a customising role that works elsewhere in the app will fail here with an unhelpful message.
Do not add Copilot agents to record-routing workstreams. It is explicitly not recommended and the behaviour is not what people expect.

Consultant notes

Whiteboard the workstream inventory before anyone touches the admin centre. One line per workstream: channel, distribution mode, capacity model, session template, fallback queue. It takes an hour and prevents the rebuild.
Push versus pick is a client operating-model decision, not a technical one. Frame it that way: push gives you control of distribution and adherence, pick gives representatives autonomy and usually better cherry-picking behaviour that supervisors will then complain about.
Demo the wrap-up setting with a stopwatch. Nothing changes a client's view on concurrency targets faster than watching capacity stay blocked while someone finishes their notes.
Before go-live, walk the fallback queue for every workstream and confirm someone is in it. This is the most common day-one incident.

Worth another look if Microsoft ever makes work distribution mode editable, or if capacity profiles change shape.