When a case is created directly from a conversation in Dynamics 365, the Case Origin field (caseorigincode) doesn’t always reflect the channel the conversation came from. Instead, it defaults to Web. This is the expected system behaviour; if no default value is set in entity metadata when getting data from Channel Integration Framework, the system assigns the value of caseorigincode to Web. This means that all conversations types handöed via CIF will get the same origin value, as this behavior hasn’t really kept up with the expanded set of channels (like voice, SMS, social, etc.).
For accurate reporting and routing, it’s important that the case origin matches the actual channel the customer used. Luckily, we can take control of this.
Options for Overriding the Default
There are a few ways to set caseorigincode dynamically:
1. Through Power Automate by triggering on case creation to update the case origin code already set when the record is saved.
2. Using a plugin to intercept the case creation in the pre-operation stage and set the correct value before the record is saved.
3. Try a reference table mapping between caseorigin (on case table) and channeltype (on conversation table).
For this business case, I chose to use Power Automate. The volume of cases created directly from a conversation is quite sparse and the value is not time-sensitive and must be set immediately, but needs to be in place in time for reporting, so even with a possible delay in the flow running, there is no actual impact on neither reporting nor other business processes. Adjusting the value via a flow also makes the solution easily adjusted if more channels are implemented at a later stage.
Step-by-Step: Setting Case Origin with Power Automate
As I’m fairly new at building flows, it could perhaps do with some fine tuning, but here’s how I structured my flow to dynamically set the case origin code.
Step 1: Trigger the flow on case creation (table Ärenden/Incident) where caseorigin does not equal email.
Step 2: List the conversation (table Konversationer) where regarding object id equals the output inlcuding incidentid from the trigger action.
Step 3: Initialize a variable that will hold the channel type value from the identified conversation (in step 2: List related conversations) by using formula
string(first(outputs(’List_related_conversations’)?[’body/value’])?[’msdyn_channel’])
Step 4: Add a condition for channel type. In my condition I work with the value (192360000) that represents channel type Chat.
Step 5a: If the condition is met and the related conversation came in through the chat channel, update the case origin (field Ursprung) to Chat (value Chatt), on the case.
Step 5b: if the condition is not met, add a nested condition to match against channel type value for the voice channel. And if this condition is met, update the case origin (field Ursprung) to Voice (value Telefon), on the case.
This elimination methos by using nested conditions works fine if you only work with a couple of different channels, but might need re-designing if you are to add several new channels in your solution.
Why This Matters
With this setup, your reporting and analytics instantly become more accurate. It’s a small tweak, but one that has a significant and important impact on reporting. You’ll know how many cases come in via chat vs. phone vs. email. And your customer service representatives get cleaner case records that reflect the true customer journey.
Tracking origin helps organizations to identify specific areas where self-service tools (such as Copilot Agents) can be implemented or improved, as well as another layer of channel volume not only in terms of handled conversations but the result in longer-term case management, which in turn affects workload and resource planning for the service representatives.
Lämna ett svar