Overview

In this scenario the requirement is to assign Dynamics 365 case priorities dynamically on the creation of the case which are being brought in from an external system. The case with the highest priority should be the next handled by their customer service agents.

When the case is created, it's location in the queue of cases pending review needs to be calculated and then a case priority value assigned to it.

There are 3 rules, if a case meets the requirements for Rule 1, then it is applied. Else, if it meets the requirements for Rule 2, then that is applied, otherwise apply Rule 3.

Rule 1 cases have a higher priority than Rule 2.

Rule 2 cases have a higher priority than Rule 3.

Rules

Priority Rule 1: Priority A 10 day counter is not blank

Priority Rule 2: Priority B 90 day counter is not blank and value is less than or equal to 50

Priority Rule 3: Cases where Priority B 90 day counter is greater than 50 days 

For each of the various rules, the internal ordering of the cases in that range should follow these rules:

• Rank incidents based on the number in the Priority A 10 day counter or Priority B 90 day counter field, where the lesser the number, the higher the ranking priority
• If multiple incidents exist with the same number of days, select the one with the highest monetary value (Euro amount)
• If multiple incidents exist with the same number of days and Euro amount, select the one with the earliest date of submission

The solution that we used here was to use a decimal numeric range for the Case Priority.

• Priority Rule 1 cases would have a rating between 2 and 3
• Priority Rule 2 cases would have a rating between 1 and 2
• Priority Rule 3 cases would have a rating between 0 and 1

The higher the rating, the more important the case.

For each case that comes in, we identity its position in the queue, then determine the rating of the case before and after it, add them together, half them and assign that rating to the new case.

Worked Example

The maximum value for a Rule 1 case is 3, the minimum value is 2.

1. When the first Rule 1 case is created, it identifies that it is the only case, so it takes the max and min, adds them together (2 + 3) = 5 and halves the value: 5/2 = 2.5
2. When the next case comes in, if it has a lower priority than the first case in Rule 1, then its priority will be the difference between the minimum value and the case after it: ( 2 + 2.5 ) / 2 = 2.25
3. The next case is less important than the first case, but more important than the second case, so its priority will be (2.25 + 2.5)/2 = 2.375

So now we have three cases in Rule 1, with this ranking in the queue.

When a new case that is more important than Case 1, it's rating with be (2.5+3)/2 = 2.75 and is now the top of the queue.

By using decimals we can assign the priority each time without having to alter the ratings for other cases in that rule.

North52 Decision Suite

The North52 Decision Suite solution works like this:

• A server-side Formula is created on the Case entity that will carry out the following steps:
  • Determine if the Prioritization rule should fire
  • Identify which Priority Rule to apply
  • Set the applicable minimum and maximum ranges for the Priority Rating
  • Identify all other Cases that are affected by that rule
  • Calculate the Priority of the current Case and set it

Set Up Formula

Create a new North52 Formula of type Decision Table with the following settings:

• Formula Type is Save - Perform Action
• Event is Create & Update
• Source Entity is Case
• Source Properties will be Dispute Amount, Priority A 10 Day Counter and Priority B 90 Day Counter fields

Sheet 1 - Validation

This sheet will determine if we need to apply the rules against these cases:

We check if either Priority A 10 Day Counter or Priority B 90 Day Counter contain a value, and if the Dispute Amount field is populated. If yes, we proceed with the calculations, otherwise we exit the Decision Table.

Sheet 2 - Priority Ranges

Here we set the maximum and minimum ranges for the various rules. As business rules evolve these ranges can be changed if required:

Sheet 3 - Select Priority Rule

Based on which fields contain data and the values in them, we decide if we apply Priority Rule 1, Priority Rule 2 or Priority Rule 3:

Sheet 4 - Retrieve Relevant Cases

Based on the selected Priority Rule, we use FetchXML to retrieve all cases that this rule applies to, and set the default minimum and maximum priorities:

Sheet 5 - Determine Index of Current Case

We count the number of cases returned by the FetchXML, if there is only 1 result, then it is the case we are currently working on:

If there is more than 1 case, we need to determine the location of the this case in the returned collection of cases. We could just loop over the records and find our case, but that's not very efficient. If there were 2000 cases it would be very slow to loop and check every result. Instead we will use North52's xCache functionality which is extremely efficient:

SmartFlow(

  xCacheLoadLocal('relevantRecords', GetVar('Case Entity Collection')), 

  xCacheAddCalculatedFieldLocal('relevantRecords', 'n52index', 'autoincrement', ''),

  xCacheGetLocal('relevantRecords', 'n52index', '?', '0', 'incidentid= "'+[incident.incidentid]+'"')

)

The formula logic above will carry out the following:

1. Using xCacheLoadLocal() load the entity collection retrieved by the FetchXML into an in-memory data table
2. With xCacheAddCalculatedFieldLocal() we add another column called n52index to the data table with the value of autoincrement (for every row in the table the value will increase by one)
   • The first row will have a value of 0 in the n52index field
   • The second row will have a value of 1 etc.
3. We then use xCachleGetLocal() to return the value of the n52index where the value in the incidentid field is the same as the case we are executing the formula against

This process is much faster than looping over an entity collection, and is much more scalable for scenarios where there could be thousands of records.

Sheet 6 - Calc Priority

Once we have determined the number of records and the index position of our case we begin calculating it's priority:

Possible scenarios:

1. Only 1 case and index position is 0
   • The only case scenario: Half the sum of the Min and Max Priority
2. Multiple cases and index position is 0
   • The highest priority case scenario: Sum the Max priority and priority of previously highest priority case and divide by 2
3. Multiple cases and index position is the same as the count of records
   • The lowest priority case: Sum the Minimum priority and priority of the previously lowest priority case and divide by 2
4. Multiple cases and index position somewhere in the middle of the entity collection
   • Sum the priorities of the cases on either side and divide by 2

We use xCacheGetLocal() and the n52index to retrive the values we need. 

xCacheGetLocal('relevantRecords', 'n52demo_casepriority', '?', {Current Case Index} +1 )

This will retrieve the value of the Case Priority field from the in-memory collection called releveantRecords at the row number Current Case Index + 1 (i.e. the value of the Case Priority on the in the record just behind this case in the queue).

The result of the calculation is the stored in Calculated Priority.

Sheet 7 - Update Priority Field

The final step is to update the Case Priority field:

Sheet 8 - Global FetchXml

This sheet holds the three FetchXML Queries that are needed to retrieve the cases for the rules:

Cases  that match with the Priority Rule 1 requirements

 

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">

  <entity name="incident">

    <attribute name="title" />

    <attribute name="ticketnumber" />

    <attribute name="createdon" />

    <attribute name="incidentid" />

    <attribute name="n52demo_casepriority" />

    <attribute name="n52demo_prioritya10daycounter" />

    <attribute name="n52demo_disputeamount" />

    <order attribute="n52demo_prioritya10daycounter" descending="false" />

    <order attribute="n52demo_disputeamount" descending="true" />

    <order attribute="createdon" descending="false" />

    <filter type="and">

      <condition attribute="n52demo_prioritya10daycounter" operator="not-null" />

    </filter>

  </entity>

</fetch>

 

Cases  that match with the Priority Rule 2 requirements

 

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">

  <entity name="incident">

    <attribute name="title" />

    <attribute name="ticketnumber" />

    <attribute name="createdon" />

    <attribute name="incidentid" />

    <attribute name="n52demo_casepriority" />

    <attribute name="n52demo_disputeamount" />

    <attribute name="n52demo_priorityb90daycounter" />

    <order attribute="n52demo_priorityb90daycounter" descending="false" />

    <order attribute="n52demo_disputeamount" descending="true" />

    <order attribute="createdon" descending="false" />

    <filter type="and">

      <condition attribute="n52demo_prioritya10daycounter" operator="null" />

      <condition attribute="n52demo_priorityb90daycounter" operator="not-null" />

      <condition attribute="n52demo_priorityb90daycounter" operator="lt" value="50" />

    </filter>

  </entity>

</fetch>

 

Cases  that match with the Priority Rule 3 requirements

 

<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="false">

  <entity name="incident">

    <attribute name="title" />

    <attribute name="ticketnumber" />

    <attribute name="createdon" />

    <attribute name="incidentid" />

    <attribute name="n52demo_casepriority" />

    <attribute name="n52demo_disputeamount" />

    <attribute name="n52demo_priorityb90daycounter" />

    <attribute name="n52demo_networkcounter" />

    <order attribute="n52demo_priorityb90daycounter" descending="false" />

    <filter type="and">

      <condition attribute="n52demo_prioritya10daycounter" operator="null" />

      <condition attribute="n52demo_priorityb90daycounter" operator="not-null" />

      <condition attribute="n52demo_priorityb90daycounter" operator="gt" value="50" />

    </filter>

  </entity>

</fetch>

 

Testing the Formula

Once the Formula is set up, we test it with a set of cases. The following 6 Case records are created:

1. When the first case is entered it is the only Priority Rule 1 case, so it's rating is half the max and min (2 + 3)/2 = 2.5
2. The next case has a higher value for the Priority A 10 Day Counter, so its rating is the min rating plus the next lowest case (2 + 2.5) / 2 = 2.25
3. The next case has value of 8 in Priority A 10 Day Counter, so it is the new lowest priority Rule 1 case, therefore it is (2 + 2.25)/2 = 2.125
4. The next case has a value of 8 in the Priority A 10 Day Counter, but a higher euro value for dispute amount. So its rating is (2.125 + 2.25) / 2 = 2.1875
5. The next case has a value of 1 in the Priority A 10 Day Counter, so it's rating is the max rating plus the rating of the previously highest rated case: (2.5 + 3) / 2 = 2.75
6. The final case that is added has a value in the Priority B 90 Day Counter, and since it is the only one in that range it takes the mid position, (1 + 2) / 2 = 1.5

The cases as they are being created and the priority being assigned to them:

The cases listed in descending order on the Case Priority field: