web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Microsoft Dynamics CRM (Archived) / Case Creation: Busines...
Microsoft Dynamics CRM (Archived)

Case Creation: Business Process Error - TimeTrackingCacheLoader

(0) ShareShare
ReportReport
Posted on by stevewicks 725

I have a single default SLA set up on our on-premise organization. when i do not associate business hours with the SLA my new cases are created and the relevant SLA timers are populated. When I add a simple 0800-1800 business hours schedule i get a Business Process Error with a message TimeTrackingCacheLoader encountered some errors{0}, see log for more detail. I've set up an identical SLA on an online instance and do not get the error. I'm assuming the issue is the calendar but cannot see why it is working online but not for the on-premise. Has anyone encountered this?

*This post is locked for comments

I have the same question (0)
  • MichBeck Profile Picture
    MichBeck 5 on at

    I have the same issue. Anybody who can help or have you find a solution?

  • STH Profile Picture
    STH on at

    Me too! Is this a Microsoft bug?

  • ColinB Profile Picture
    ColinB 15 on at

    I'm getting the same thing.  SLA works fine until Business Hours are added!

  • ColinB Profile Picture
    ColinB 15 on at

    Given up and logged a call with Microsoft.

  • Craig Fitzgerald Profile Picture
    Craig Fitzgerald on at

    With Microsoft's help I've managed to resolve this problem for our CRM.

    Check that you can access the Discovery Service URL internally, i.e. from the CRM application server. Go to Settings > Customizations > Developer Resources and then click on the discovery service link.  You should see a test page load saying you've created the service.

    With our IFD CRM the discovery service starting dev.domain.com was the external address, but the internal address was internalcrm.domain.com.  We couldn't ping dev.domain.com internally, so by adding a DNS entry for this, pointing to the CRM Application server IP address, it now seems that the Customer Service Schedule process can now load correctly and we no longer get any errors.

    We've also noticed that we had to recreate all of the Customer Service Schedules - the ones we created before seemed to be calculating the time incorrectly for some reason.

  • ColinB Profile Picture
    ColinB 15 on at

    Thanks for the update Craig, I've not heard back from Microsoft yet.  I've tried this but my SLA's are not being calculated properly and even though I have recreated by Customer Service Schedules they are miles out.  Any suggestions?  Did you have to recreate your SLA's or Holiday Schedules?

    thanks in advance.

    Colin

  • Craig Fitzgerald Profile Picture
    Craig Fitzgerald on at

    Hi Colin, we didn't have to recreate the SLA, but we tested without the business hours to make sure they were working correctly.  However, we did have a similar issue with the times seeming to be wildly out when adding the business hours and realised that a 1 day SLA is 24 hours spread over the number of available hours in your Customer Service Schedule.

    i.e. our Customer Service Schedule has 10 hours availability.  So a 1 day SLA is 24 hours, meaning the SLA time is set to 2 days and 4 hours (2x10 hour days and 4 remainder).  So we changed the 1 day SLA to 10 hours and this resolved the problem.

    Hope that helps.

  • STH Profile Picture
    STH on at

    I don't understand this part, could somebody explain further please?

    With our IFD CRM the discovery service starting dev.domain.com was the external address, but the internal address was internalcrm.domain.com.  We couldn't ping dev.domain.com internally, so by adding a DNS entry for this, pointing to the CRM Application server IP address, it now seems that the Customer Service Schedule process can now load correctly and we no longer get any errors.

    We don't have a discovery service that looks like xxx.domain.com, I don't think we have IFD?

  • stevewicks Profile Picture
    stevewicks 725 on at

    Just an update on this. By implementing the steps above we had case creation (inc automatic), with SLA & business hours working for a week without issue. Suddenly we have had overnight failures - all with the TimeTrackingCacheLoader showing in the auto case creation system job log. Curiously, on the first occasion, they restarted of their own accord while we were investigating possible causes. Unfortunately the following night (last night) the same thing has happened. As yet we're still scratching our heads and they have not restarted by magic. I'll leave the question marked as answered but I feel we now need some more input from Microsoft.

  • Steve Le Monnier Profile Picture
    Steve Le Monnier 959 on at

    We've been following the posts on this forum closely as we've also discovered a number of problems around the SLA engine. Here is what we have discovered and can confirm.

    Firstly, we can confirm that the SLA engine works in calander days not business days. Which explains why some are seeing target dates greater than one might expect. For us our SLA is to warn after 1 day and resolve after 2 days. Because a day for us is 8am to 6pm (10 hours) Mon-Fri, we had to enter the SLA as warn after 10 hours and fail after 20 hours. Once the business hours schedule is taken into affect it will calculate the correct target dates.

    However. having had this working correctly we started to change the number of hours to wait (for testing purposes rather than waiting that physical amount of time) and we noticed some strange behaviour. When we asked it to wait 17 hours it correctly calculates the target time as 17:45 on the correct day. But when we changed the SLA to wait 18 hours, rather than picking the following morning at 8.45 it skipped an additional day!

    We have logged a call with Microsoft but so far they have been unable to recreate the issue, although they have not fully tested this as yet as they did not use a time delay as great as ours, just enough time to reach the critical 5pm to 6pm range. We suspect the number of hours may be significant in the calculations the engine uses. We are also in the UK which is GMT +1 for BST to add to the complications.

    Secondly, after trying to test the target dates from the SLA engine for the first 7 days. We too are now having a Business Process Error (TimeTrackingCacheLoader) error that started on the 8th day of July and remains broken. The only way we can create cases now is to detach the Business Hours from the SLA then the error goes away.

    We've tested this on another clean server with very simplified rules and it remains broken there too. So we are suspecting the problem may be our time zone or the number of days into the month we have now reached. I say this because one of the errors captured in the tracing files states "String was not recognized as a valid DateTime" is this a US month first date problem affecting UK/EU customers... just a thought?

    This second issue is quite serious for us as it's brought the whole system down. I'm just about to log a call with Microsoft, but if anybody has any additional thoughts on what is going on here please post on this forum. If I get any positive feedback from Microsoft I will also update this page.

    Regards

    Steve

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Congratulations to the November Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics CRM (Archived)

#1
SA-08121319-0 Profile Picture

SA-08121319-0 4

#1
Calum MacFarlane Profile Picture

Calum MacFarlane 4

#3
Alex Fun Wei Jie Profile Picture

Alex Fun Wei Jie 2

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans