Almanac

Consultant-focused KB for Microsoft Dynamics 365 Contact Center: implementation notes, gotchas, and configuration decisions beyond the official docs — across voice and digital channels, routing, agent and supervisor experience, Copilot & AI, workforce engagement, analytics, administration and security.

feature-wem-app.mdv1 · history
CurrentApplies to BothUpdated 15 hours agoSource Microsoft Learn

Status: Public Preview — behaviour may change.

What it does

The Workforce Engagement Management app is a standalone Dynamics 365 app that puts workforce management and quality management in one place, instead of spreading them through the Copilot Service workspace site map. It's an alternative front end over capabilities you already have — it doesn't replace Copilot Service workspace and doesn't change an existing deployment.

Key facts

  • Preview, and single-session only. Multisession isn't supported, which rules it out for anyone who needs it docked alongside live conversation handling.
  • Needs the Workforce Management for Customer Service package installed from the Power Platform admin centre — the same package the embedded WFM experience uses. No separate install.
  • The app is only visible to users holding one of the new WFM roles or one of the three quality management roles. No role, no app in the launcher.
  • Two areas: Workforce management (Planning, Scheduling, Monitoring) and Quality management (Evaluation, Governance, Screen recordings).
  • Planning covers planning groups, operation calendars, forecasting, capacity planning and external historical data import. Scheduling covers shift plans, shift rotations, shift bookings, requests management and the schedule calendar. Monitoring covers shift summary, adherence tracker, intraday performance and adherence historical analytics.
  • Admin settings sits at the bottom of the site map, so an administrator can configure WFM and quality management without going to Copilot Service admin centre. The admin centre still works — this is a second door to the same settings.
  • User management is the exception: Admin settings > User management links out to Copilot Service admin centre rather than handling it in-app.
  • Procedures are unchanged from the existing articles. Where a WFM article names a Copilot Service workspace location, the equivalent node exists in the app under the same name.
  • Workforce alerts appear in admin settings still marked preview in their own right.

When to use / skip

Use it where workforce planners, schedulers, intraday analysts and quality managers are dedicated roles who never handle conversations — they get a tool that matches their job rather than a supervisor console with WFM bolted into it. Skip it for anyone who needs multisession, and skip it as a migration target: there's nothing to migrate to, and the embedded experience isn't going anywhere on the strength of this.

Configuration decisions

  • Whether to introduce the app at all, or stay on Copilot Service workspace. Running both is supported and is the realistic answer during preview.
  • Which users get the new granular WFM roles and which keep Omnichannel supervisor. The two role sets coexist, so you can pilot per-user.
  • Whether administrators configure WFM from the app or from Copilot Service admin centre. Pick one as the convention or you'll get two groups of admins with different mental models of where settings live.
  • Whether quality management users move here as well — their roles are the existing three, so the decision is only about which UI they open.

Gotchas

  • Assigning the quality management roles is not app-scoped. Quality Admin, Quality Manager and Quality Evaluator govern quality management everywhere, so granting one to make the app visible also changes what that person can do outside it. The WFM roles are the opposite — app-only.
  • Single-session in preview is the practical blocker. A supervisor who monitors adherence between conversations can't use this app for it yet.
  • The app appears in the user's app list only at next sign-in after the role is assigned, which reads as "it didn't work" to the user standing over your shoulder.
  • Nothing about this changes the underlying data or configuration, so an A/B between the two UIs is genuinely safe — but it also means a misconfiguration made in the app is a misconfiguration everywhere.

Consultant notes

  • The real content here is the role model, not the app. Clients have been asking for years how to let a forecaster forecast without making them an Omnichannel supervisor, and this is the first answer. Scope the conversation around that and the app itself becomes an implementation detail.
  • Expect a scoping trap: someone reads "standalone app" and assumes it's a licensing or deployment change. It isn't — same package, same data, same environment, different site map.
  • The quality-roles-are-global asymmetry is the thing that bites in UAT. A client grants Quality Manager to five people purely so the app shows up for them, and discovers those five can now edit evaluation criteria in the existing experience too. Check who already holds these roles before you use them as an app-visibility key.
  • Don't build a go-live plan on this while it's single-session. Pilot it with planners and schedulers who work in it all day, and leave supervisors on Copilot Service workspace until multisession lands.

Worth revisiting after the next release wave — particularly for the multisession limitation and whether the WFM roles leave preview.

Was this accurate?