The partner consultancy I run, SOLO Cloud Solutions, uses Dynamics 365 Customer Engagement as our internal CRM system to manage potential sales opportunities and customer caseloads. I’m a firm believer in “eating your own dog food” when it comes to the technology solutions our organisation supports and, by ensuring we use the very same tools we are proponents of to our end customers, we can best understand the benefits and, sometimes, frustrations that come with these systems and, all being well, appear credible to our end customers when recommending a particular solution to adopt. With this in mind, our business can benefit significantly on the one hand - by leveraging features such as Entitlements or SLA’s to ensure we can keep track and respond quickly to our customer’s needs - and, on occasion, grapple with issues and frustrations on the other hand. This reality doesn’t distract from my real favour for Dynamics 365 as a business solution; it’s just a natural expectation of any software system a business chooses to adopt. 😉

To illustrate this point more plainly, let me share a real frustration we faced involving the system and how we got around it. For some of our customers, we track the number of hours we consume on each Case via an Entitlement. These Cases can cover two types of issues:

1. Break/Fix where the solution isn’t working due to a fault on our side or via Microsoft. Our support agents will typically pick these up and work through to resolution.
2. Enhancement or change requests requiring a modification to an existing solution. In all cases, these will be passed along to an appropriate consultant (maybe even me!) to progress and implement accordingly.

Under the support agreements, we do not typically deduct/consume hours for issues where the system has broken. As we have dedicated colleagues to handle support issues, this is “soaked up” as part of our support agreement. We only then need to potentially charge, track and (potentially) invoice the customer for work that sits outside of this and, typically, requires the expertise of a trained consultant to satisfy. So, for the latter scenario, colleagues logging Cases in the system need to press the appropriate Do Not Decrement Entitlement button to ensure hours are not deducted from the Entitlement:

So far, so good - all of this is native functionality in the application and an absolute doddle to set up. Things start getting a bit trickier when we need to report back to customers on how we’ve consumed hours for both scenarios. Scenario 2) presents little difficulty in obtaining, but 1) proves, as far as I know (answers on a postcard if you disagree), more irksome generate. However, as they say, where there is a will, there’s a way. 😁 Using a bit of FetchXML wizardry, we can look to construct a query similar to the one below to generate the information we need for both scenarios, with a clear flag field to indicate whether the hours fit into scenario 1) or 2):

<fetch aggregate="true">
  <entity name="incidentresolution">
    <attribute name="totaltimespent" alias="incidentresolutionsum" aggregate="max" />
    <link-entity name="activitypointer" from="activityid" to="activityid" link-type="inner">
      <link-entity name="incident" from="incidentid" to="regardingobjectid" link-type="inner" alias="incident">
        <attribute name="incidentid" alias="incidentid" groupby="true" />
        <attribute name="decremententitlementterm" alias="decremententitlementterm" groupby="true" />
        <filter>
          <condition attribute="entitlementid" operator="eq" value="094b0dcc-df24-ec11-b6e6-000d3a0cb337">
            <value>094b0dcc-df24-ec11-b6e6-000d3a0cb337</value>
          </condition>
        </filter>
      </link-entity>
    </link-entity>
  </entity>
</fetch>

Using arguably the best XrmToolBox app, we can then get a result back that looks like this:

From there, we can then sum up all of the True values to determine the hours consumed for scenario 2); everything else will be a break/fix issue.

Now, there’s a couple of things to remember with this solution:

• You will need to update the value used in the entitlementid condition to match your environment and Entitlement…in case that wasn’t obvious. 😀
• It’s expected we always associate a Case to an appropriate Entitlement for the customer. This has the benefit of ensuring that we can always tag the correct SLA. For reporting purposes, this also provides a common attribute for us to filter on for each period we are concerned with (for us, we typically have an Entitlement per calendar quarter for each customer).
• Our primary table used is the incidentresolution table, which indicates we’ve resolved the Case. We then implement grouping and aggregation to return the maximum totaltimespent value from this, representing the actual amount of time spent on the Case and accounting for any scenarios where the Case may have been re-opened.
• For this approach to work, we instruct our agents to raise and close Tasks, via the Timeline control, on the Case row for all actions they perform, recording the amount of time it takes to complete each one in the process. This ensures that the time rolls up correctly when the Case is closed.

But apart from that, this solution works well for our purposes and makes it quick and easy to generate the information we need during our quarterly reviews with customers. As stated, it’s a shame that we have to revert to a more complex query to get this information, but I’m willing to admit that our particular scenario may be somewhat niche. Hopefully, if you’ve found yourself in the same boat from a requirements standpoint, then this approach will help you as well. And it goes a long way to proving the point over the potential versatility of the Dynamics 365 Customer Service application. Provided, of course, you know what you’re doing… 😅