From your screenshots, your configuration appears to be following the expected Unified Routing architecture, although there are a couple of UI behaviors that can certainly be confusing.
Here are my thoughts on each of your questions:
1. Why is the Case entity missing from the Record Type dropdown?
This is not expected behavior. If the Case (Incident) table has been successfully onboarded under Routing > Record routing, it should normally be available when creating a Record workstream.
A few things I'd verify are:
- The Case entity has completed onboarding successfully (no pending provisioning).
- Omnichannel configuration changes have fully propagated (Microsoft notes this can take up to 15 minutes).
- Required Customer Service/Omnichannel apps and solutions are installed and up to date.
- You're working in the same environment where the entity was onboarded.
- Browser cache/metadata refresh (which you've already tried).
Since creating the workstream directly from Record routing succeeds, this points more toward a UI metadata synchronization issue than a configuration problem. If the behavior persists across browsers and after sufficient propagation time, it may be worth raising a Microsoft support ticket.
2. Is the workaround supported?
Yes. Creating the workstream from the Record routing page ultimately provisions the same Unified Routing workstream. The navigation path is different, but the underlying workstream and routing configuration are the same.
If everything functions correctly (routing, queue assignment, prioritization, etc.), I wouldn't expect any architectural differences simply because it was created from the Record routing experience.
3. Why is the root record "Conversation" instead of "Case"?
This is expected.
Unified Routing processes work items through the routing engine using a Conversation abstraction, even for record-based routing scenarios. The routed business record (in your case, Case) is attached to that conversation.
Because of this, routing conditions commonly navigate through:
Conversation → Routed record (Case) → Case attributes
So configuring conditions like:
- Routed record (Case) contains data
- Priority = Low
is the supported approach for evaluating Case fields during routing.
This design allows the routing engine to provide a consistent processing model across multiple work item types (cases, chats, custom records, etc.) while still exposing the underlying record attributes for routing decisions.
Overall, based on the screenshots, your routing rule configuration looks correct. The only unusual part is the missing Case entity in the initial Record Type dropdown, which appears to be a UI/metadata issue rather than an architectural limitation.
I'd also be interested to hear if others have encountered this behavior in recent Customer Service releases, as it may be related to a recent admin center UI update rather than an environment-specific configuration.
