Fix Dynamics 365 Omnichannel Agent Disconnections and Chat Timeouts
A troubleshooting guide for agents being dropped mid conversation in Omnichannel for Customer Service, and how to make the disconnections stop.
Agents getting disconnected mid chat? This guide diagnoses the common causes: session restore settings, conversation timeouts, and browser policies. We give step-by-step fixes for the Customer Service admin center and for reconnection window configuration, based on our own Dynamics 365 Customer Service implementation experience. Most "random" Omnichannel disconnections are not random at all. They come from a Dataverse session or inactivity timeout, an Entra ID sign-in frequency policy, a workstream inactivity rule, agent presence flipping, or a proxy quietly killing the long lived connection the app depends on. Start by asking agents what they actually saw, because each symptom points at a different layer of the stack.
Is it a Microsoft known issue or something in your own setup?
Check this first, before anyone touches a timeout. When Omnichannel drops chats across the board, a service incident in your region is a real possibility, and changing settings during one adds new problems without fixing the old one. Three places tell you in a few minutes. Admin center menus move between releases, so follow the current Microsoft documentation for the exact path.
Microsoft 365 admin center: Service health
Under Health, Service health lists active incidents and advisories for your tenant, including the Dynamics 365 and Power Platform services Omnichannel depends on. Open anything that is active, read the scope and the stated user impact, and note the incident ID and the time it started. If the start time lines up with the first complaints, you have your leading explanation, and the job becomes containment and evidence rather than configuration. You need a role that can read service health, so agree in advance who in the support team holds it.
Microsoft 365 admin center: Message center
Message center carries planned changes rather than outages: feature updates, deprecations, and behaviour changes rolling out to your tenant, including those for Dynamics 365 Customer Service. A change to the agent workspace, presence, or a browser requirement that reached your tenant the night before the drops started is worth reading before you blame your own settings.
Power Platform admin center: service health and known issues
The Power Platform admin center surfaces service health and known issues against your environments, and it shows the region each environment is deployed in. Check the region of the production environment your agents use, because incidents are often scoped to one geography, and a clean status for a different region tells you nothing. The support request flow in the same admin center also checks for known issues matching what you describe before you raise a ticket.
A clean status page does not prove the platform is healthy, and an open incident does not prove it is the cause. The pattern of who is affected settles it.
| Signal | Points to a platform incident | Points to your configuration or network |
|---|---|---|
| Who is affected | All agents, in every team, at more or less the same moment | Some agents only: one team, one capacity profile, one shift, or a group of new starters |
| Which work is affected | Every workstream and channel at once, often with other Dynamics 365 apps slow or failing too | One workstream or one channel, which points at that workstream configuration rather than the service |
| Where agents are | Every office, home worker, and network at once | One site, one VPN gateway, or one virtual desktop image, which points at the network or browser policy |
| When it started | A clean start time with nothing in your own change log, often matching an entry in Service health | Shortly after a release, a timeout change, a conditional access change, a proxy change, or a new browser policy |
| What agents saw | The service itself erroring or failing to load for everyone, including admins in the admin centers | A sign-in prompt, a conversation vanishing, or a chat going silent, matching one row of the triage table below |
If it does look like an incident, contain the damage as described below, collect the evidence, and raise a support request from the admin center quoting the incident ID, then leave the configuration alone until Microsoft reports it resolved. If it does not, the triage table and the step by step diagnosis below take over.
How do you contain a live disconnection crisis while you find the cause?
When a major client is watching their customers lose conversations, the diagnosis cannot be the only thing happening. These four actions run in parallel with it, and they are ordered so the evidence you need later survives the containment you do now.
Pause new routed conversations on the affected workstream
Stop feeding live chats into a channel that is dropping them. Depending on how your chat widget is deployed, that means taking the widget off the affected pages, switching it to its offline or out of hours message, or turning off proactive chat, and pointing customers at email, phone, or a callback form in the meantime. If only some agents are affected, set those agents to a presence that does not receive work so routing sends new conversations to agents who are stable. Record what you paused and when, so it can be put back deliberately.
Tell the affected client before they tell you
Send the client a short, factual note: what customers are experiencing, what has been paused, which channel their customers should use instead, and the time of your next update. Then keep to that time even if there is nothing new to say. Follow up individually with customers whose conversations dropped, using the conversation transcripts, so nobody is left waiting on a chat that no longer exists. Silence during a disruption does more damage to the relationship than the disruption.
Preserve the diagnostics before anyone refreshes or reconfigures
On an affected machine, open the browser developer tools with log preservation turned on and capture a HAR file across a drop, together with the console output. Write down the conversation IDs of dropped conversations, the agent sign-in names, and exact timestamps with the time zone. Ask the network team to keep proxy and firewall logs for the same window and the identity team to export the sign-in log entries. A HAR file contains tokens and customer message content, so store and share it as sensitive data and remove what is not needed before it leaves your organization.
Change one thing at a time, and write each change down
Under pressure several people change several settings at once, and when the drops stop nobody knows which change worked or which one caused the next problem. Put one person in charge of changes, keep a timestamped log, and if Service health shows an active incident, change nothing in configuration at all until Microsoft reports it resolved.
Where the disruption goes wider than chat, for example integrations failing at the same time, our integration and Omnichannel emergency triage guide sets the wider order of work.
Which kind of disconnection are your agents actually having?
Agents use the word "disconnected" for at least four different failures, and each one lives in a different part of the stack. Ask them what they actually saw before you change a single setting.
| What the agent saw | What it means | Where to look |
|---|---|---|
| The agent is thrown back to the sign-in screen and has to authenticate again | This is an identity or platform session expiry, not an Omnichannel fault. The whole app went, not just the chat. | Dataverse session timeout and inactivity timeout in the Power Platform admin center, plus Entra ID conditional access sign-in frequency. |
| The app stays open but the conversation vanishes from the session panel | The conversation was closed or reassigned away from the agent. The client is still connected; the work item moved. | Workstream inactivity and auto close settings, notification timeout and reassignment behaviour, and the agent presence that was in force at that moment. |
| The conversation is still on screen but messages stop arriving in both directions | The persistent connection between the browser and the Omnichannel service dropped while the page stayed loaded. | Proxy, VPN, and firewall idle timeouts on websocket traffic, required endpoints, browser tab suspension, and machine sleep or wifi power saving. |
| The agent presence keeps flipping to Away or Offline and new chats stop arriving | Presence is being changed by inactivity or by a second session, so unified routing stops treating the agent as available. | Presence configuration, the agent running the app in more than one tab or device, and capacity or profile assignment. |
If different agents describe different symptoms, you have more than one cause running at the same time. That is common, and it is why a single configuration change often only fixes part of the complaints.
What causes agents to disconnect mid chat?
Dataverse session timeout and inactivity timeout
The most commonly missed cause, because it is not an Omnichannel setting at all. In the Power Platform admin center, under the environment settings for privacy and security, an environment has a maximum session length and an optional inactivity timeout. When either expires the user is signed out of the whole app, chat included, and has to authenticate again. An inactivity timeout set aggressively for compliance reasons will log out an agent who has been reading rather than typing, in the middle of a live conversation.
Entra ID conditional access sign-in frequency
A conditional access policy with a short sign-in frequency, or with a policy that re-evaluates on network or device state change, forces a token refresh mid conversation. If the refresh cannot complete silently the agent is bounced to a sign-in prompt. This one is easy to overlook because it is owned by the identity team rather than the Dynamics 365 team, and it usually appears after a security tightening exercise rather than after a Customer Service release.
Workstream inactivity and automatic closure rules
Each workstream can end a conversation after a period of customer inactivity, typically with a warning message first and then an automatic close. There are also settings that close a session automatically after wrap up. When these are configured tighter than the real rhythm of a conversation, for example while a customer is looking up an order number or an agent is waiting on a back office check, the conversation closes on its own and the agent reports it as a disconnection.
Notification timeout and conversation reassignment
When unified routing offers a conversation, the incoming notification has a timeout. If the agent does not accept in time, the work item is rejected on their behalf and routed to somebody else. Combined with a slow loading session tab or a busy agent, this looks exactly like being disconnected from a chat that was already theirs, when in fact the assignment never completed.
Presence changing automatically, or a second session stealing it
Omnichannel decides whether to route work to an agent based on presence. Presence can move to an inactive or away state on its own, and it is shared across the user, not per tab. An agent who opens the Customer Service workspace in a second browser tab, a second browser, or on a second machine can end up with the first session losing its grip on live conversations. Running the workspace in one tab only is the supported pattern, and it removes a whole class of unexplained disconnects.
Proxy, VPN, and firewall idle timeouts on the live connection
Omnichannel keeps a long lived connection open between the browser and the service so messages arrive in real time. Corporate proxies, VPN concentrators, and packet inspection appliances routinely apply an idle timeout to that connection and close it while the page stays open. The agent sees a chat that has gone quiet in both directions. Required Microsoft endpoints also have to be reachable and not intercepted, otherwise the reconnect attempt fails silently.
Browser policies, tab suspension, and blocked storage
Microsoft Edge sleeping tabs and Chrome memory saver can suspend the workspace tab when the agent switches away, which tears down the live connection. Enterprise browser policies that block third party cookies or clear site data on exit, along with strict tracking prevention, aggressive ad blockers, and some extensions, break the frames and storage the app relies on. Locked down virtual desktop images are a frequent source of this because the policy set is applied fleet wide and nobody tests it against the agent app.
Machine sleep, wifi power saving, and thin client sessions
A laptop that sleeps, a wifi adapter allowed to power down, or a virtual desktop session that disconnects will all drop the connection even though nothing is wrong with the configuration. This is worth ruling out early for home based agents, because the pattern of complaints looks environmental rather than tenant wide once you plot who is affected.
Session restore expectations after a refresh or crash
Agents often expect a browser refresh, a crash, or a sign out to leave their conversations exactly where they were. What actually survives depends on your session settings and on how long the agent was gone, because the conversation can be reassigned in the meantime. When restore behaviour is not configured and communicated, normal product behaviour gets reported as a bug, which sends the investigation in the wrong direction.
How do you diagnose and fix the disconnections step by step?
Work through these in order. Step 1 rules a Microsoft incident in or out, steps 2 and 3 narrow the problem down, steps 4 to 9 find the cause in the platform, the routing configuration, the network, and the browser, and steps 10 and 11 apply and validate the fix.
Check service health and known issues for your region first
Before changing any setting, open Service health and Message center in the Microsoft 365 admin center and the service health and known issues information in the Power Platform admin center, and look for an active incident or recent change affecting Dynamics 365, Customer Service, or the Power Platform in the region your production environment runs in. Then test the pattern: if all agents, all workstreams, and every site were hit from one clean start time with no change on your side, treat it as a probable platform incident, contain it, collect evidence, and raise a support request quoting the incident ID. If only some agents, one workstream, or one site are affected, it is almost certainly yours, so carry on to the next step.
Classify the disconnection before changing anything
Ask the affected agents one question: when it happened, were you sent back to the sign-in screen, did the conversation disappear from your session list, or did the chat stay on screen and go silent? Those three answers point at identity, at routing configuration, and at the network layer respectively. Changing timeout settings before you have classified the symptom is how teams spend a week fixing the wrong thing.
Plot who is affected, and when
Collect the affected users, their locations, their devices, their browsers, and the timestamps. If it is one site or one VPN gateway, it is a network problem. If it is everyone at the same time of day, look at a scheduled policy or a session length that started when the shift did. If it is only agents on a locked down virtual desktop image, it is browser policy. This costs an hour and removes most of the candidate causes.
Check the environment session and inactivity timeouts
In the Power Platform admin center, open the environment, then the privacy and security settings, and read the session timeout and the inactivity timeout. Compare them against a real agent shift. An inactivity timeout that is shorter than a long customer conversation will sign agents out mid chat by design. Adjust it to a value your security team accepts and your agents can actually work within, and record the decision so it does not get tightened again by accident.
Review conditional access sign-in frequency with the identity team
Ask whoever owns Entra ID to list the conditional access policies that apply to the agent group, and specifically the sign-in frequency and any session controls. Check the sign-in logs for the affected users at the exact timestamps you collected. An interactive re-authentication landing in the middle of a conversation is visible there, and it proves the cause is identity rather than Omnichannel before anybody touches the workstream.
Audit the workstream inactivity, closure, and notification settings
In the Customer Service admin center, open the affected workstream and read every timing value it has: the customer inactivity warning and automatic closure, any automatic session closure after wrap up, and the notification timeout on the notification template used when work is offered. Compare each one with how long your conversations genuinely take. Lengthen the values that are firing early, and test the change on a single workstream before applying it everywhere.
Confirm presence behaviour and enforce a single session per agent
Check the presence configuration and the capacity or capacity profile assigned to the affected agents, then confirm that nobody is running the Customer Service workspace in more than one tab, browser, or machine at once. Make single tab working an explicit rule in the agent guidance. This is the cheapest fix on this list and it clears a surprising share of the reports that survive the first four steps.
Prove or clear the network path
With the network team, confirm the required Microsoft endpoints for Omnichannel and Dynamics 365 are reachable and not intercepted by TLS inspection, and check for an idle timeout on the proxy, VPN, or firewall that is shorter than a quiet period in a chat. Reproduce on a machine outside the corporate network for a direct comparison. If the disconnections stop off network, the fix belongs to infrastructure and no amount of admin center configuration will help.
Standardize the browser and its policies for agents
Settle on a supported browser for agents, then turn off tab sleeping or memory saver for the Dynamics 365 origin, allow the cookies and site storage the app needs, exempt the origin from strict tracking prevention, and test with extensions disabled to identify anything that interferes. Push this as policy to the agent fleet rather than leaving it to each agent, and verify it on the actual virtual desktop image if that is what agents use.
Configure and communicate reconnection behaviour
Configure the customer side reconnection on the live chat channel so a customer who loses the page can rejoin the same conversation within a defined window rather than starting again with a new agent, and set the session behaviour you want on the agent side after a refresh or crash. Then tell the agents what will and will not be restored. A known reconnection window turns a disconnection from an incident into a recoverable event.
Fix in a sandbox, then validate with real conversations
Apply each change in a non production environment, then run a deliberate test that includes a long quiet period, a browser refresh, a tab switch, and a machine lock, because those are the moments that break. Only then promote the change. Keep monitoring the ongoing conversation and agent dashboards for a full week afterwards, since some of these causes only appear on a particular shift or from a particular office.
Where does each setting live, and what does it actually control?
Labels move between releases of the Customer Service admin center and the Power Platform admin center, so this table is organized by what a setting does rather than by the exact wording on your screen. Check every row before you conclude the product is at fault.
| Setting | Where it lives | What it does to a live chat |
|---|---|---|
| Session timeout and inactivity timeout | Power Platform admin center, environment settings, privacy and security | Signs the agent out of the entire app when the maximum session length or the inactivity period is reached. Ends live conversations as a side effect. |
| Sign-in frequency and session controls | Microsoft Entra ID conditional access policies | Forces re-authentication on a schedule. If it cannot complete silently the agent is sent to a sign-in prompt mid conversation. |
| Customer inactivity warning and automatic closure | Customer Service admin center, the workstream for the affected channel | Warns and then ends a conversation after a quiet period. Set too tight, it closes conversations that are simply waiting on somebody. |
| Automatic session closure after wrap up | Customer Service admin center, workspace and session settings | Closes the session tab once wrap up completes. Useful, but it surprises agents who expect the tab to stay open. |
| Notification timeout on the notification template | Customer Service admin center, notification templates used by the workstream | Controls how long an agent has to accept an offered conversation before it is reassigned. Too short and work is pulled away before it is accepted. |
| Presence and capacity configuration | Customer Service admin center, agent presence, capacity profiles, and user records | Decides whether unified routing considers the agent available. Presence is per user, not per tab, so a second session interferes with the first. |
| Reconnection to a previous chat conversation | Customer Service admin center, the live chat channel on the workstream | Lets a customer who lost the page rejoin the same conversation within a defined window instead of starting a new one with a different agent. |
| Tab sleeping, memory saver, cookies, and tracking prevention | Browser enterprise policy, applied to the agent fleet and the virtual desktop image | Suspends the workspace tab or blocks the storage and frames the app needs, tearing down the live connection while the page stays open. |
Two of these rows are not owned by the Dynamics 365 team at all. Conditional access belongs to whoever runs Entra ID, and browser policy belongs to end user computing. If you cannot get those two answered, the investigation will stall no matter how carefully you audit the workstream.
Which changes need the network team rather than a Dynamics admin
Send each request to the team that can actually make the change. A Dynamics 365 admin cannot lengthen a proxy idle timeout, and a network engineer cannot fix a workstream that closes conversations too early.
| Change | Who makes it |
|---|---|
| Proxy, VPN, and firewall idle timeouts on long lived connections, websocket support, TLS inspection bypass, and reachability of the required Microsoft endpoints | Network and security team |
| Conditional access sign-in frequency and session controls, and reading the sign-in logs | Identity team that runs Microsoft Entra ID |
| Tab sleeping, memory saver, cookie and tracking prevention policy, extensions, and the virtual desktop image | End user computing or desktop team |
| Environment session timeout and inactivity timeout | Power Platform administrator, with sign-off from security |
| Workstream inactivity and closure, notification timeouts, presence, capacity, and reconnection settings | Dynamics 365 Customer Service administrator |
| An active Microsoft incident or known issue | Microsoft, through a support request raised from the admin center; your part is the evidence and the containment |
How does Solzet run this on a client environment?
Solzet is a Microsoft Dynamics 365 Customer Engagement and Power Platform consultancy in Yerevan, Armenia. Disconnecting agents is one of the issues we are called in for most often on Customer Service work, usually after the internal team has already changed a few timeout values without the complaints stopping. We start by classifying the symptom and plotting who is affected, because that alone rules out most of the candidate causes, then we work the platform, identity, routing, network, and browser layers in that order and validate the fix in a sandbox before it goes anywhere near production.
On the Microsoft side we work in Dynamics 365 Customer Engagement and the Power Platform: Sales, Customer Service including Omnichannel and unified routing, Field Service, model driven and canvas apps, Power Automate, Power Pages, Dataverse, plug-ins and custom APIs, and PowerApps Component Framework controls. For organizations where Microsoft licensing is not the right fit, we also build custom CRM on React, Node.js, PostgreSQL, and .NET. We do not take on Business Central or Finance and Operations work, so if that is where your problem sits we will say so at the first conversation.
If your Customer Service problems go wider than disconnections, our SLA timer pauses guide covers the other symptom service leads report most, and the rescue and takeover guide includes a worked remediation of unified routing, workstreams, and queues in Omnichannel for Customer Service. If you are still choosing a platform, we compare Dynamics 365 Customer Service against Zendesk for a Microsoft 365 shop, and the wider service is described under Dynamics 365 consulting.
What do people ask about Omnichannel disconnections?
Why do my Dynamics 365 Omnichannel agents keep getting disconnected mid chat?
In practice it is one of five things. A Dataverse session or inactivity timeout on the environment signs the agent out of the whole app. An Entra ID conditional access sign-in frequency policy forces a re-authentication mid conversation. A workstream inactivity or automatic closure rule ends the conversation on its own. Agent presence changes, often because the workspace is open in a second tab or on a second machine, so unified routing reassigns the work. Or a proxy, VPN, or firewall applies an idle timeout to the long lived connection the app keeps open. Classify the symptom first, because each of those sits in a different place.
Is there a known issue causing Dynamics 365 Omnichannel agents to disconnect mid chat?
Check before you change anything. Open Service health and Message center in the Microsoft 365 admin center, and the service health and known issues information in the Power Platform admin center, and look for an active incident or recent change affecting Dynamics 365, Customer Service, or the Power Platform in the region your production environment runs in. A platform incident usually hits all agents, all workstreams, and every site from one clean start time with nothing in your own change log. If only some agents, one workstream, or one site are affected, the cause is almost always your configuration, identity policy, browser, or network, and the diagnostic steps on this page apply. Menu names move between releases, so follow current Microsoft documentation for where these pages sit.
Our Omnichannel chats keep dropping and a major client is affected. What do we do right now?
Contain, communicate, and preserve evidence in parallel with the diagnosis. Pause new routed conversations on the affected workstream by taking the chat widget offline or switching it to its offline message, and point customers to email, phone, or a callback. Send the client a factual note with what is paused, the alternative channel, and the time of your next update, and follow up with customers whose chats dropped. Before anyone refreshes or reconfigures, capture a HAR file and console output across a drop, the conversation IDs, agent sign-in names, and exact timestamps with time zone, and ask the network and identity teams to keep their logs for that window. Then change one setting at a time, and nothing at all while Microsoft shows an active incident.
Which Omnichannel disconnection fixes need the network team rather than a Dynamics 365 admin?
Proxy, VPN, and firewall idle timeouts on long lived connections, websocket support, TLS inspection bypass, and reachability of the required Microsoft endpoints all belong to the network and security team, and no admin center setting can fix them. Conditional access sign-in frequency belongs to the identity team, and tab sleeping, cookie policy, extensions, and virtual desktop images belong to end user computing. The Dynamics 365 Customer Service admin owns workstream inactivity and closure, notification timeouts, presence, capacity, and reconnection, and the Power Platform admin owns environment session and inactivity timeouts. Send each request to the right team on the first day.
How do I stop Omnichannel for Customer Service chats from timing out too early?
Open the affected workstream in the Customer Service admin center and read its timing values: the customer inactivity warning, the automatic closure that follows it, any automatic session closure after wrap up, and the notification timeout on the notification template. Compare each against how long your conversations really take, including the pauses while a customer looks something up. Lengthen the values that are firing early, change one workstream at a time, and confirm the fix with a deliberate test that includes a long quiet period.
Is the session timeout in the Power Platform admin center the same as the Omnichannel conversation timeout?
No, and confusing the two is the most common reason these investigations stall. The session and inactivity timeouts in the Power Platform admin center are platform level and sign the user out of the whole application, chat included. The inactivity and closure settings on an Omnichannel workstream end a single conversation while the agent stays signed in. If the agent lands on a sign-in screen it is the platform setting or conditional access. If the app stays open and only the conversation disappears, it is the workstream configuration or reassignment.
Can browser settings really disconnect an Omnichannel agent?
Yes, and it is one of the most under investigated causes. Edge sleeping tabs and Chrome memory saver can suspend the workspace tab when an agent switches away, which drops the live connection. Enterprise policies that block third party cookies or clear site data on exit, strict tracking prevention, aggressive ad blockers, and some extensions break the storage and frames the app depends on. Locked down virtual desktop images are a frequent source because the policy set is applied fleet wide and rarely tested against the agent app.
What is the reconnection window and how do I configure it?
On the live chat channel of a workstream you can allow a customer whose page dropped to rejoin the same conversation within a defined period, instead of starting a new chat with a different agent. Configure that window to something realistic for your customers, and separately decide and communicate what agents should expect after a browser refresh or crash, because what survives depends on your session settings and on whether the conversation was reassigned while they were away. A known reconnection window turns a dropped chat into a recoverable event rather than a lost customer.
Does running Customer Service workspace in two tabs cause disconnections?
It causes exactly this class of problem. Presence and session state belong to the user rather than to a browser tab, so a second tab, a second browser, or a second machine can interfere with the conversations already running in the first. Running the workspace in a single tab is the supported pattern. Making that an explicit rule in agent guidance is the cheapest fix on this list and it resolves a meaningful share of reports that survive the configuration checks.
How do I prove whether it is the network rather than the configuration?
Collect the affected users, sites, devices, and exact timestamps. If the problem tracks a single office or VPN gateway, it is the network. Confirm with the network team that the required Microsoft endpoints are reachable and not subject to TLS inspection, and check for an idle timeout on the proxy, VPN, or firewall that is shorter than a quiet period in a chat. Then reproduce on a machine outside the corporate network. If the disconnections stop off network, no amount of admin center configuration will fix it.
Can Solzet fix disconnecting agents in our Omnichannel for Customer Service setup?
Yes. Solzet is a Microsoft Dynamics 365 Customer Engagement and Power Platform consultancy based in Yerevan, Armenia. We run exactly these diagnostics on client environments as part of our Customer Service implementation, optimization, and project rescue work: classifying the symptom, checking the platform and identity timeouts, auditing the workstream and unified routing configuration, working with the network and browser policy owners, and validating the fix in a sandbox before it reaches production. We work directly with end clients and white-label for Microsoft partners.
We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both.
Agents still dropping mid chat? Can we find the cause for you?
Tell us what your agents actually see when they lose a conversation and we will work it through the platform, identity, routing, network, and browser layers until the disconnections stop. Solzet delivers Dynamics 365 Customer Engagement and Power Platform work from Yerevan, Armenia, directly for end clients and white-label for Microsoft partners across Europe and the US.