Details about this thread
  • State Not Answered
  • Replies 5 replies
  • Subscribers 310 subscribers
  • Views 1328 views
  • Users 0 members are here
Related content from around SugarClub

Time to Resolution cases

Missy Brooks

We have been waiting for the opportunity to capture case duration. After upgrading to 9.1 on cloud, we found ourselves with the Resolution Date already in the Cases record view, so users began using it, up until case wouldn't close and the resulting error message referred to something like, "cannot be resolved before created." 

So now, we can capture duration, but the problem exists where users must create cases in real-time. For our needs, sometimes a case is created after the fact because it was a weekend call, they were onsite and an issue came up, too much going on - so the case was created later / solved later. 

Because the system timestamps the Date Created and uses that against the Resolution Date / time to establish the total time spent on the case, we are looking to make this work for us, while still maintaining a level of flexibility about delaying a case's creation, but accurately depicting its duration. 

 I did find this, but it will give the same problems (must create the case in real-time) 

https://support.sugarcrm.com/Knowledge_Base/Workflows/Capturing_Case_Close_Date_and_Time_to_Resolution/index.html 

We may be out of luck on this one, or just have to have some cases outside the norm. Any thoughts or help would be appreciated!

  • 0 Sugar Employee Badge

    Hi Missy Brooks,

    This is a great question, and how it is approached depends on how you envision your system working.

    I understand the scenario of cases being made after they are resolved, and you still needing to capture the amount of time they took to resolve even though the entire duration of the case predates the case record's existence.

    You are also correct that the core functionality of the Resolution Field is to validate that it is after the Date Created.

    Are you using a different field other than Date Created to calculate the case's duration against the Resolution Date? If so, would disabling the validation on the Resolution Date field fulfill your need?

    Doing so will require custom code. I am asking just to get a sense of the potential solution that would serve your need in this described issue.

  • 0 in reply to Patrick McQueen

    Hi Patrick McQueen,

    We are not. We have always used only a field named "Duration" that users manually populated with a total number of hours, days or weeks. I have hidden the "Resolved Date" on the record view for now because of the issue with Cases not closing that I mentioned. But would like to be able to utilize it - and also begin capturing duration automatically as well, according to the workflow capability mentioned in the document link (if either is possible). 

  • 0 in reply to Patrick McQueen

    You got me thinking....

    In the documentation Capturing Case Time to Duration, the dependent formula is shown as:

    ivide(abs(subtract(hoursUntil($date_entered),hoursUntil($date_case_closed_c))),24)

    Could this still work in conjunction with another criteria / formula? such as 

    ivide(abs(subtract(hoursUntil($date_man_entered),hoursUntil($date_case_closed_c))),24)

    My (wishful) thinking is:

    1. Could I created a "Real-time Case" (just ex) checkbox, etc on the case record to be checked IF it isn't being created in real-time.

    2. When checked, a dependent field "Date Manually Created" (date_man_created), becomes available for users to populate. The Date Created is still captured, but is disregarded (?)

    3. The formula then gathers either the date created OR the date manually created to be used against the Resolution Date for Case Duration.

    Question: could those co-exist? and if so, could they be written as to disregard one or the other based on the "Real-time Case" status? 

  • 0 Sugar Employee Badge in reply to Missy Brooks

    Hi Missy Brooks,

    Doing this entirely custom can look like this:

    Fields

    date_entered - Stock record creation date populated automatically.

    date_man_entered_c - Custom DateTime field for user manual date created entry

    date_case_closed_c - Custom DateTime field for user manual resolution entry

    duration_c - Custom Integer field calculated

    Formula in Duration_c

    ifElse(greaterThan(strlen(toString($date_man_entered_c)),0),divide(subtract(number(timestamp($date_case_closed_c)),number(timestamp($date_man_entered_c))),3600),divide(subtract(number(timestamp($date_case_closed_c)),number(timestamp($date_entered))),3600))

    I hope this helps!

  • 0 in reply to Patrick McQueen

    Anxious to test this out in our test instance; willl update! Thanks!!