SLA tracking and reporting in Sugar similar to that offered by JIRA?

Just an update with my own research and findings here.

Out of the box, Sugar's Case Management is rather simplistic compared to a dedicated ticketing solution like JIRA. But Sugar's ease of extendibility to model the business requirements was a key in pursuing this an as option.

After cutting a fair bit of code to implement SLA timers, here's an outline of the solution. For commercial reasons I cannot share the code.

Requirement -

We needed SLA and other timers on a case to know how long a case was open, how long until a first response by a tech, and how long a case was in certain statuses (for calculating SLA breaches). SLA timer thresholds were defined in a custom module 'Agreement'. There were six values relating to a case priority (1,2,3) and if a case resolution could be done on site or off site. 

If a case's SLA timer exceeded a threshold, it would go into a "Breach' state.

Solution Outline - 

- Using Process Author or 3rd Party workflow solutions to update a field (eg no. minutes) was not granular enough or reliable for SLA timer calculations. We could not rely on the scheduler to run exactly every minute. Over many hours/days the time calculations would drift.

- So we implemented a custom scheduler. It ran through all open cases each 5 minutes (thus giving cases a granularity of 5 minutes. We thought 1 minute might unnecessary load the server). I used a custom field on each case called something like 'last_schedule_run' to calculate the number of seconds since the scheduler last processed the case. That way irrespective of when the scheduler ran, we knew exactly how much to increase the SLA timer by.

SierraCRM was used as a workflow solution where emailing and alerts relating to a case were required. For example emailing a manager if a case went into a breach.

- Global javascript was used on a timer to colorise the rows of a case depending on it's priority and status. While I'd prefer to not use a timer based approach, is was the easiest in that one lot of code would colorise cases whether they were on a dashboard, a case list view or in another modules subpanel. Initially I tried extending record views, but it was just to many files with too much similar code to be practical.

- Another scheduler was created to generate reports weekly and/or monthly for clients. It would find cases for the week/month period and email out a case report to each client. Reporting requirements were defined in the custom 'Agreement' module.

- Custom modules were also created for Equipment and Customer Sites that can be covered by different agreements.

I still love, recommend and use JIRA. It's was the ability to model Equipment, Agreements and Sites and link them all together that made Sugar shine!

Dashboard. Cases are colored depending on their status and SLA Timer.

An "Agreement" with SLA thresholds. An Agreement specifies support expectations for equipment, sites and services.

Just an update with my own research and findings here.

Out of the box, Sugar's Case Management is rather simplistic compared to a dedicated ticketing solution like JIRA. But Sugar's ease of extendibility to model the business requirements was a key in pursuing this an as option.

After cutting a fair bit of code to implement SLA timers, here's an outline of the solution. For commercial reasons I cannot share the code.

Requirement -

We needed SLA and other timers on a case to know how long a case was open, how long until a first response by a tech, and how long a case was in certain statuses (for calculating SLA breaches). SLA timer thresholds were defined in a custom module 'Agreement'. There were six values relating to a case priority (1,2,3) and if a case resolution could be done on site or off site. 

If a case's SLA timer exceeded a threshold, it would go into a "Breach' state.

Solution Outline - 

- Using Process Author or 3rd Party workflow solutions to update a field (eg no. minutes) was not granular enough or reliable for SLA timer calculations. We could not rely on the scheduler to run exactly every minute. Over many hours/days the time calculations would drift.

- So we implemented a custom scheduler. It ran through all open cases each 5 minutes (thus giving cases a granularity of 5 minutes. We thought 1 minute might unnecessary load the server). I used a custom field on each case called something like 'last_schedule_run' to calculate the number of seconds since the scheduler last processed the case. That way irrespective of when the scheduler ran, we knew exactly how much to increase the SLA timer by.

SierraCRM was used as a workflow solution where emailing and alerts relating to a case were required. For example emailing a manager if a case went into a breach.

- Global javascript was used on a timer to colorise the rows of a case depending on it's priority and status. While I'd prefer to not use a timer based approach, is was the easiest in that one lot of code would colorise cases whether they were on a dashboard, a case list view or in another modules subpanel. Initially I tried extending record views, but it was just to many files with too much similar code to be practical.

- Another scheduler was created to generate reports weekly and/or monthly for clients. It would find cases for the week/month period and email out a case report to each client. Reporting requirements were defined in the custom 'Agreement' module.

- Custom modules were also created for Equipment and Customer Sites that can be covered by different agreements.

I still love, recommend and use JIRA. It's was the ability to model Equipment, Agreements and Sites and link them all together that made Sugar shine!

Dashboard. Cases are colored depending on their status and SLA Timer.

An "Agreement" with SLA thresholds. An Agreement specifies support expectations for equipment, sites and services.