Almanac
Microsoft/d365csDynamics 365

Consultant-focused KB for Microsoft Dynamics 365 Customer Service: implementation notes, gotchas, and configuration decisions beyond the official docs — across case management, queues and routing, knowledge base, SLAs, omnichannel, agent experience, Copilot, analytics, and administration.

feature-agent-experience-inbox.mdv1 · history
CurrentApplies to EnterpriseUpdated 6 days agoSource Microsoft Learn

What it does

The inbox is a single pinned tab in the workspace app that lists everything assigned to the agent — cases, emails, tasks, chats, voice, voicemail and unified-routing-enabled records — as cards they can triage without opening a session for each one. Work stays in the inbox until the agent promotes it to a full session.

Key facts

  • The inbox is enabled per experience profile, under Inbox on the profile, and configured through the Settings icon there. It is off in some profiles by default, so agents on the wrong profile simply don't see the tab.
  • Supported record types: case, email, task, live chat, asynchronous chat (SMS, persistent chat, Facebook, WeChat, LINE, WhatsApp, Teams), voice, voicemail, and records routed through unified routing.
  • Four preconfigured views ship: Cases, Assigned Conversations, Resolved Conversations and Unassigned Conversations.
  • Views auto-refresh every five minutes. Agents can refresh manually; there is no setting to make it more frequent.
  • Configuration comes in two flavours. Simple settings give you fixed scopes per record type — assigned to me, in my teams, in my queues, sent to me, shared mailbox, and so on. Advanced settings open a condition builder plus custom sort by entity attribute.
  • Advanced settings also allow bringing your own tables into the inbox, so custom work item tables can be triaged alongside cases.
  • Channel-focused inbox behaviour decides where an incoming conversation lands: add to inbox only if the agent is currently in the inbox, always add to inbox, or always open in a new session.
  • Voice calls always open as a session regardless of that setting; a card is added to the inbox for awareness only.
  • Agents can personalise their own inbox views and rearrange or add attributes on the work item cards.
  • Promoting an inbox item opens it as a normal session, and it then counts against the nine-session limit like anything else.
  • Live work items show unread counts and activity indicators, which is the main reason chat-heavy teams want it.

When to use / skip

The inbox earns its place where agents receive a mixed stream — a few chats, a queue of emails, and cases arriving by routing — and are expected to decide what to touch next. It gives them a triage surface that doesn't consume sessions. Skip it for teams working a single channel from a dashboard view they already trust; you'll be replacing a view they like with a card list that shows less. Also skip it where supervisors assign work explicitly and agents have no discretion about order, because the inbox is fundamentally about agent-chosen priority.

Configuration decisions

  • Which record types belong in the inbox at all. Everything you add dilutes the list; email plus one conversation type is often enough.
  • Simple settings or the advanced condition builder. Advanced buys precision at the cost of a config nobody else on the team will understand in a year.
  • Whether custom tables are surfaced through bring-your-own-entity, and what their card should show.
  • The channel-focused behaviour setting — whether conversations interrupt the agent with a session or wait in the inbox.
  • Sort order per view. This is the closest thing agents get to a work-priority instruction, so it deserves a conversation with the operations lead.
  • Whether agents are allowed to build personal views, or whether the client wants a uniform triage experience.

Gotchas

  • The five-minute refresh interval is not configurable. Clients who expect a live queue display will be disappointed, and telling them to hit refresh doesn't land well after go-live. Set the expectation during design.
  • Unassigned Conversations shows team queue work, which means agents can see and take items the client may have intended supervisors to distribute. Check that against the routing design.
  • Inbox views are subject to normal security. An agent who can't read a queue's records gets a shorter list than the design document promised, and there's no message explaining why.
  • Promoting several inbox items in a row is the fastest way to hit the nine-session ceiling. Agents who treat the inbox as a parking bay hit it daily.
  • Turning the inbox on changes where routed conversations land, depending on the channel-focused setting. Enable it mid-project and agents will report that chats have stopped arriving when in fact they're queuing in the inbox.
  • Card attribute personalisation is per user. Support will get "my inbox looks different to hers" tickets and there is no admin reset.

Consultant notes

  • Demo the inbox next to the client's current queue dashboard and let them compare directly. It usually wins on mixed workloads and loses on single-channel ones — better to find that out in a workshop than in UAT.
  • Agree the channel-focused behaviour with the operations lead, not with IT. It's a working-practice decision dressed as a setting.
  • Keep the view count low. Four views agents actually use beats twelve they scroll past.
  • Test the inbox with a realistic volume of records, not a demo dataset of six. Card lists behave differently at 200 items.
  • Before go-live, confirm each persona's profile has the inbox toggle in the intended state. It's a per-profile setting and it is routinely missed on the supervisor profile.

Worth another look if the refresh interval becomes configurable or the inbox picks up real-time updates.

Was this accurate?