Microsoft is deprecating the Unified Service Desk (USD), and many teams are now searching for the right next step. The good news: there’s no direct 1:1 replacement, but there is a well-supported path forward — moving your USD configurations back into native Dynamics 365 Customer Service capabilities, primarily through Customer Service workspace (CSw). This guide walks through exactly how to make that transition, covering:
- Replacing USD configurations with multi-session experiences
- Defining your own workspace using templates and productivity tools
- Managing session context to keep customer context
- Use Macros and agent scripts to automate
- Modernizing forms with custom pages
- Replacing toolbars with ribbons
- Putting your customization files back in your solutions
- Moving options and user settings to settings or environment variables
Keep in mind that not all functionalities will return, so it is important to review what is supported before planning your transition.
Replace USD configurations with multi-session experiences
A key feature of USD is the ability to support multiple customers at the same time. This capability was introduced in Dynamics 365 Customer Service through Customer Service workspace (CSw), making it a logical fit for Contact Center users.
For teams that want to build their own experience, multi-session support can be enabled in a custom model-driven app. The app still behaves like a standard model-driven app but now supports sessions. By linking security roles to model-driven apps, different users can receive tailored experiences, similar to USD configurations.
This already covers much of the experience, and experience profiles let you refine it further by defining which session templates and tools are available.
Replaces: configurations
More details multi-session experience: https://theappsbakery.com/deliver-your-own-multi-session-experience/
More details experience profiles: https://learn.microsoft.com/en-us/dynamics365/customer-service/administer/overview
Define your own workspace
The layout of USD could be heavily customized so you can create your own tools and position them where you want them. Model-driven app experiences are more structured, so not every component can be placed everywhere. This pattern sounds limiting at first. However, the layout is easier to manage. It typically consists of three areas:
- Left: channel integration, such as Dynamics 365 Contact Center or any third party channel (e.g. Genesys)
- Middle: the different applications
- Right: productivity tools, where previous hosted controls can be placed
Replaces: custom layout
Bring your own work with templates
Where in USD there are hosted controls which show you contents in a session, CSw has application templates. There are three important things to know about:
- Anchor tab; the first session is an anchor tab this application is always created in every session
- Application templates are templates; on the contrary to hosted controls multiple applications can exist in a session
- Global no longer exists; applications are always tied to sessions so closing or switching sessions with change all applications.
With these things in mind – it is important to look at the type of templates which can be selected. The type of templates makes the content which can be shown like in any model driven app:
- Entity list; show a view of records
- Entity record; show a single record
- Web resource; show a web resource
- Dashboard; a dashboard
- Search; search panel for records.
Where the ones above cover the basics, there are three which make your experience really powerful.
- Custom; embed custom pages which can be used to create forms or simple processes.
- Control; a PCF control – here is were the true power lies – make your own user experience for processes or user interface
- Third party website; embed website – be aware though that it does not use browsers like USD but will be embedded as iframes.
Warning: since websites are no longer separate browsers, website not supporting iframes won’t be able to be embedded. Look at move this functionality to API’s or other ways or integration.
Warning #2: by default the controls will refresh every time you return to the page. This behavior can be overridden programmatically.
Each of these templates has parameters which indicate what should be in the application templates. These parameters also support data slugs so you can do flexible parameters.
Replaces: hosted controls
More details application templates: https://learn.microsoft.com/en-us/dynamics365/customer-service/administer/application-tab-templates
Add tools to increase productivity
Productivity tools help agents work more efficiently by bringing useful features into their workspace. Standard options include agent scripts, Copilot, and Teams chats. You can extend the experience further by creating your own custom productivity tools.
These tools are a valid replacement for hosted controls. They enable you to support functionality which isn’t provided out of the box.
Replaces: hosted controls
More details productivity tools: https://theappsbakery.com/make-your-own-productivity-tool-for-agents/
Manage context for your sessions
Sessions bring back context, just like USD did. Each session carries its own context, and you can fill it with any data relevant to that customer.
You can access this context through scripting to pull the values you need. Alternatively, data slugs let you insert those values directly — in session titles, application templates, or Macros.
The example below shows how to set up a slug. Channel data populates these fields automatically, or they fill in when a new item is created.
- {customerName}
Data slugs can also be used to retrieve data via an OData requests – which makes that not all data needs to be in context.
- {$odata.account.name.?$filter=accountid eq ‘{customerRecordId}’}
Replaces: session lines, scriptlets, entity searches
More details data slugs: https://learn.microsoft.com/en-us/dynamics365/customer-service/administer/automation-dictionary-keys
Use Macros and agent scripts to automate
USD enabled advanced scenarios to automate the agent experience, powered by actions, action calls, and events.
These features are not returning to CSw in the same form. Basic scenarios can be covered with macros and agent scripts, which provide useful automation options.
For teams that use Copilot extensively, event-driven automation can also be handled through Copilot-based capabilities.
Replaces: actions, action calls, events and agent scripts
Modern forms with custom pages or generative pages
Forms aren’t returning in CSw. In USD, this was solved by embedding PowerApps directly. In CSw, use custom pages instead — they’re the recommended way to cover form-based scenarios.
Replaces: forms
Replace toolbars with ribbons
In USD, toolbars gave administrators the flexibility to build a command bar without touching the existing ribbons. Moving back to model-driven apps means working with the ribbon again — buttons now need to be added or removed there directly.
The Ribbon Workbench makes this process efficient. A simple trick like using separate forms per role helps you hide buttons for specific users without affecting everyone else.
Replaces: toolbars
Put your customization files back in your solutions
All templates and their dependencies (e.g. webresources or controls) are solution aware so they can be included in a solution. This means that customization files are no longer needed.
Important: the relationship between templates cannot be added via the user interface. Make sure you add the parent component, then the children including the relationships will be added.
Replaces: hosted controls, forms, customization files
Move options and user settings to settings or environment variables
Since USD relies heavily on context, settings and user settings are the way to toggle features or get variables clear. With CSW, this focus was reduced making it rely more on the app that on the context.
Since the platform grew there were two initiatives which enabled this all – one being environment variables and the other settings. With environment variables you put a lot of variables on an environment level in your solution and can configure the values for them while importing or through deployment profiles. They can be easily retrieved through the Web API or the function RetrieveEnvironmentVariableValue.
This works great, but especially when using multiple apps or more fine grained settings this becomes challenging. The introduction of settings gives us the possibility to define these settings not only on environment level but also on an app level. This makes that you can toggle feature on or off per app.
var settingValue = Xrm.Utility.getGlobalContext().getCurrentAppSetting(settingName);
Replaces: options and user settings
More details environment variables: https://learn.microsoft.com/en-us/power-apps/maker/data-platform/environmentvariables
More details settings: https://learn.microsoft.com/en-us/power-apps/developer/model-driven-apps/clientapi/get-update-setting-value-using-code
Not all functionalities will be returning
Window navigation rules won’t be supported at all since CSw is browser based and will only support iFrames. This means that functionality like routing to different windows won’t be possible anymore. Other simple functionality, like preventing navigation, is possible through disabling the clicking of lookup fields.
Learn more to disable clicking: https://learn.microsoft.com/en-us/dynamics365/release-plan/2026wave1/service/dynamics365-field-service/disable-clickthrough-lookup-values-forms
Scriptlets are not possible with data slugs, you can provide your own JavaScript to do these kinds of tricks.
User Interface Integration (UII) automation was functionality in USD, CCA and CCF to automate web pages. In USD, this was already a low priority in USD. With the introduction of CSw this functionality is not provided. With the introduction of Copilot, Copilot has becomes part of the solution to help you with these requirements. More about this soon.
Migrating off USD touches nearly every layer of your service desk — sessions, templates, forms, automation, and settings — so it’s worth planning the transition carefully rather than moving piece by piece under pressure. If you’re mapping out your own USD migration and want a second set of eyes on the plan, get in touch — we’ve guided several teams through this exact move.
