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.
First, work out which disconnection you have
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.
Common causes of agents disconnecting 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.
Step-by-step: diagnose and fix the disconnections
Work through these in order. Steps 1 and 2 narrow the problem down, steps 3 to 8 find the cause in the platform, the routing configuration, the network, and the browser, and steps 9 and 10 apply and validate the fix.
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 each setting lives, and what it actually controls
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.
How we 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.
We work inside Dynamics 365 Customer Engagement and the Power Platform only: 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. 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.
Frequently Asked Questions
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.
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.
Agents still dropping mid chat? We will find it.
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.