Want help applying this guide?Ask the DripTell team
A representative is handling a difficult case and needs an expert from another team. The old swarm button is familiar, so the temptation is to look for a feature that resembles it. That is the wrong migration target.
Microsoft says the customer support swarming preview in Dynamics 365 Customer Service has been deprecated and unsupported since February 8, 2026. Its recommended direction is embedded Microsoft Teams chat. The safe replacement is not simply another place to talk. It is a record-linked consultation workflow that keeps one case owner, gives the expert enough context, records the decision and tells the customer what happens next.
Swarming is no longer the feature to design around
The current Microsoft deprecation notice is direct about the product status and the suggested alternative. That gives administrators a direction, but it does not prove that every old swarm configuration has a one-for-one equivalent.
Start by listing what the old workflow actually did. How did the representative decide that help was needed? Which experts were eligible? Who could see customer data? Did the original representative keep ownership? Where was the answer recorded? What happened if nobody joined? Those are operating requirements, not button requirements.
This distinction matters because an informal chat can solve the immediate question while leaving the case weak. The expert may answer in a conversation that later owners cannot find. The representative may assume the expert now owns the customer. The customer waits while the internal discussion appears busy.
Rebuild the job before you rebuild the tool
Use one narrow case type for the first migration. Choose work that genuinely benefits from consultation, such as a technical exception or a policy interpretation, and exclude cases that should simply be transferred. The existing guide on when to consult an expert or transfer the customer is a useful boundary.
- 1Keep one ownerThe service representative remains accountable for the customer case.
- 2Link the recordExpert discussion stays connected to the same case and history.
- 3Invite the right expertAccess and expertise are checked before collaboration begins.
- 4Record the decisionThe case carries the agreed action, owner and next customer update.
Write a small service contract for the collaboration. It should name the case owner, the question sent to the expert, the expected response window, what evidence the expert can access, the fallback when nobody responds, and the event that ends the consultation. Keep assignment visible in the conversation ownership workflow rather than treating a chat invitation as an ownership change.
Use one linked record as the collaboration anchor
Microsoft's Teams chat guidance says a group chat can be connected to a record, that administrators control relevant permissions, and that eligible representatives can join a connected chat and see its history. It also warns that a new connected chat starts fresh rather than importing earlier one-to-one chats. That last point is easy to miss.
Create the collaboration from the customer record whenever possible. Put the concise question and the facts the expert needs in the approved introduction. Do not paste unnecessary customer data into chat. Keep the customer-facing chronology in the shared inbox view, and use the case record as the source for status, ownership and promised next action.
| Decision | Evidence before launch | Owner | Failure response |
|---|---|---|---|
| Start a consultation | A specific expert question and one active case owner | Service representative | Continue ownership and use the named fallback |
| Add an expert | Correct skill, permission and availability | Team lead or routing policy | Invite a qualified alternative without duplicating chats |
| Accept advice | A clear recommendation tied to the case | Service representative | Ask for clarification before updating the customer |
| Transfer the case | New team must act directly with the customer | Current and receiving owners | Use a formal accepted handoff |
| Close collaboration | Decision and next action are recorded | Case owner | Keep it open until the record is complete |
Pilot the replacement with real edge cases
Test more than the happy path. Include a case where the suggested expert lacks record access, the first expert does not respond, a second expert joins later, the representative changes shift, and a supervisor needs to reconstruct the decision. Verify that connected-chat permissions match your data policy and that a person without record access does not gain information through a copied message.
Use the conversation status model to keep waiting for an expert separate from waiting for the customer. Those states have different owners and clocks. Test the routing fallback for cases that require direct transfer, not just advice.
The first pilot should be reversible. Run a defined cohort, retain the old operational fallback where it is still safe, and record which cases used the new path. Review whether experts joined, whether the representative remained accountable, whether the answer entered the case, and whether the customer received a meaningful update.
Measure continuity rather than chat activity
Do not use message count as the success metric. A long internal conversation can still produce no decision. Review time from consultation request to usable advice, consultations abandoned without an answer, repeated expert invitations, transfers after consultation, customer wait time and a sample of final case quality.
The inbox reporting guide can support the customer-side review, but collaboration evidence also needs a simple migration register. Record the old trigger, new path, permission owner, fallback, test date and unresolved gap. If the team cannot reconstruct why a decision was made, the replacement is not ready.
Know when consultation should become transfer
Keep the original representative as owner when the expert is advising. Transfer only when the receiving team must make the decision, perform the work or communicate directly with the customer. Require acceptance before ownership changes. This prevents the phrase “I asked another team” from becoming a hidden queue.
DripTell can preserve assignment, conversation history and next actions across a shared customer workflow, but it should not be presented as a drop-in replacement for a Microsoft preview feature. The useful question is whether your chosen workflow preserves responsibility and context. The DripTell team can help map that requirement to your current channels.
Frequently Asked Questions
Is Dynamics 365 customer support swarming still supported
No. Microsoft says the preview feature was deprecated and unsupported from February 8, 2026, and recommends embedded Teams chat for expert collaboration.
Is a Teams chat the same as a support swarm
Not automatically. A connected Teams chat can support record-linked collaboration, but you still need explicit rules for ownership, access, response expectations, fallback and recording the final decision.
Should the expert become the case owner
Usually not for a consultation. Keep the original representative responsible unless the expert's team must take direct action and formally accepts the transfer.
What should be tested before the change goes live
Test permissions, missing experts, delayed responses, shift changes, chat history, record linkage, accepted transfers and whether the final advice is visible in the case.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy