Modernising the Agent Desktop Across Eight Legacy Systems Without Replacing Them

Why unify the agent desktop instead of replacing the legacy systems?

The eight systems usually exist for good reasons: a billing platform, a policy or contract system, an order system, a legacy CRM, a document store, a telephony client, a knowledge base and something built in-house years ago. Each is a system of record for something, several carry regulatory weight, and replacing them all to fix the agent experience is a multi-year programme the operation cannot wait for.

The agent problem is narrower than the systems problem. Agents do not need eight systems replaced; they need the handful of facts and actions each interaction requires on one screen, for the right customer, without retyping. Surfacing solves that while the systems of record stay where they are, and it leaves any later consolidation free to happen one system at a time behind a surface agents already use.

Which building blocks compose a single agent surface in Dynamics 365?

The Customer Service workspace is the shell: a multisession agent experience where each customer interaction opens as a session with its own tabs, an app side pane for supporting tools, and productivity tools such as agent scripts and macros. Inside that shell, each legacy capability is surfaced with the lightest component that does the job. How these components are built belongs to our Power Platform development and PCF controls development pages; the table is about which to choose where.

How do you resolve the customer once and pass the context to every panel?

Identity resolution is the part that makes or breaks the surface. If each panel searches for the customer on its own, you have rebuilt the swivel chair inside one window. Resolve the customer at the start of the interaction and hand the result to everything else.

• Pick the anchor: the Dynamics 365 contact or account the conversation or case is linked to, identified from the caller number, email address or authenticated channel.
• Hold a cross-reference of external identifiers on that record, such as the billing account number, policy number or legacy customer ID, maintained by the integration that knows them rather than by agents.
• Where a customer has several identifiers in one system, make the agent choose once, at the start, and store the choice on the case or conversation.
• Pass the resolved identifiers to panels as parameters: custom pages receive the record through navigation parameters, embedded canvas apps receive the form record, PCF controls read bound columns, and side panes are refreshed when the session changes.
• Never let a panel fall back to a free-text search on name. If the identifier is missing, show that plainly and offer the lookup, so a wrong match cannot happen silently.
• Duplicate contacts break resolution before any code does; clean them first and keep duplicate detection rules on.

How do you reach on-premises systems without opening the network badly?

The aim is that nothing on the internet can start a connection into your data centre. Each pattern below keeps connections outbound from your network, and each limits what is exposed to the specific data and operations phase one needs, not whole databases.

How do authentication and single sign-on work across the systems?

Agents sign in to Dynamics 365 with Microsoft Entra ID, and the unified surface should not ask them to sign in again for each panel. Where legacy systems cannot accept an Entra ID token, decide deliberately whose identity each call uses, because that decision determines what your audit trail can prove.

• Prefer the agent identity end to end where the legacy system or API layer can accept Entra ID tokens, so access checks and logs name the person.
• Where a legacy system only supports a service account, put Azure API Management or a thin API in front, authenticate the agent there with Entra ID, and log the agent identity before the service account call is made.
• Store service credentials in Azure Key Vault, referenced through secret environment variables, or in connections bound through connection references, never in panel code or plain-text environment variables readable by makers.
• Apply the same authorisation rules the legacy screen applied; a panel must not show an agent data their legacy role would have hidden.
• Use Entra ID conditional access for the workspace itself, so device and location rules apply once rather than per system.

What latency budget keeps the agent screen usable?

A unified surface that takes longer to load than switching windows will be abandoned. Set a budget before building: how long the session may take to show the customer and the first panel, and how long each further panel may take. Measure against real legacy response times, because the slowest system sets the floor.

• Load the customer summary first and the rest on demand, in tabs or collapsed sections the agent opens when needed.
• Cache slowly changing reference data, such as product or contract terms, in the API layer or in Dataverse, and read volatile data live.
• Call legacy systems in parallel rather than in a chain, and show each panel as soon as its own data arrives.
• Give each call a timeout and a clear message, so one slow system never blocks the whole screen.
• Keep the case form itself light; our guide to decluttering slow Dynamics 365 case forms covers the form side.

How do you log what the agent saw for compliance?

Dataverse auditing records changes to Dataverse data, and read activity can be captured through Microsoft Purview activity logging, but neither sees a lookup made directly from a panel to a legacy API. If compliance needs to show who viewed which customer data in which interaction, log it where the call is made.

• Route panel calls to legacy systems through one API layer, and log agent, customer identifier, system, operation, time and the case or conversation ID for each call.
• Log the purpose context the agent was in, such as the session and case, so an access review can tell a legitimate lookup from browsing.
• Keep the log outside the reach of agents and makers, with retention set by your policy.
• Turn on Dataverse auditing for the tables agents change, so write-backs are recorded alongside the reads.
• Review the log periodically for lookups with no linked interaction.

What is the phased order that delivers a usable surface before full integration?

Phase by traffic, not by system. A mid-market first phase covers one or two contact reasons that account for a large share of interactions, read-only, with one team. That is small enough to deliver without an enterprise programme and large enough that agents feel the difference. The steps are below.

• 1. Map the interactions, not the systems: Observe agents on the highest-volume contact reasons and record which systems each one touches, which fields are read and written, and where identifiers are retyped between screens.
• 2. Fix the customer identity resolution: Decide which identifier each system of record uses, build a cross-reference held in Dataverse or resolved by an API, and resolve the customer once when the conversation or case opens.
• 3. Open a controlled path to on-premises systems: Expose the on-premises data and APIs needed for phase one through the on-premises data gateway, Azure Relay hybrid connections or Azure API Management over a private link, without new inbound firewall openings.
• 4. Build read-only panels for the first interaction: Surface the context agents look up most as read-only panels in the Customer Service workspace, using custom pages, embedded canvas apps, PCF controls or virtual tables, each receiving the resolved customer.
• 5. Set latency budgets and log what agents saw: Give each panel a load time budget, load non-essential panels on demand, and log every external lookup with agent, customer, system and time at the API layer.
• 6. Pilot with one team and measure: Run the surface with one team on the chosen interaction, compare handle time, errors and system switches against the baseline, and fix what agents report.
• 7. Add write-backs and the next interaction: Once reads are trusted, add the write-backs that remove retyping, then move to the next highest-traffic interaction and retire the legacy screens agents no longer open.

Should the unified desktop be built on Dynamics 365 or a custom application?

If you already run Dynamics 365 Customer Service or Microsoft 365, the workspace, routing and productivity tools are there to build on, and the work is integration and composition. If you do not, the choice is wider. 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.

A custom-built CRM on React, Node.js, PostgreSQL or .NET can be the agent surface over the same legacy systems, with the same identity, on-premises access and logging patterns, and without per-user Microsoft licensing for every agent. It also means you own the shell, including the session handling that Customer Service provides out of the box.

How does Solzet deliver agent desktop unification?

We start with observation and an interaction map, agree the first phase and its latency budget, then build the identity resolution, the on-premises access path and the first panels, and pilot with one team. Scope comes from our Dynamics 365 Customer Service implementation work, with custom pages, canvas apps and PCF controls built by our Power Platform developers. Where the legacy estate itself needs untangling, see our guide to rationalising point-to-point integrations.

Solzet delivers remotely from Yerevan, Armenia, with senior consultants and full-stack developers and 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly or white-label for Microsoft partners. We integrate with finance and ERP systems as sources, but we do not implement Dynamics 365 Finance, Business Central or other ERP systems.