Does non Service desk reporting work in Service desk?

[Mark Frear]

Hi All.

Im new to the Jira Suite, However I have started to product customer reporting from our Service desk and the results that involve the "resolved" state are showing as if the cases have not been resolved.

Ive seen the advice regarding changing what the "Done" status is configured with however our platform is a Team Managed Service desk which doesnt appear to have the "text" option next to the diagram option on the WF as per this thread). (https://community.atlassian.com/t5/Jira-Service-Management/Resolved-Tickets-and-Reporting/qaq-p/1584430.

As a result of this, it appears that all our service desk cases are unresolved so standard Jira reporting (case age, time in status etc) are showing as blank/cases open since Jira started being used.

The Service Desk report "time to done" does accurately reflect the case resolution hence the initial question, are the reports for jira not compatible with Service desk?

Any help would be greatly appreciated.

Thanks

[Emre Toptancı _OBSS_]

Hello @Mark Frear ,

For Jira, a resolved issue is one that has a value in its "Resolution" field. Most built-in reports calculate results based on this.

Another possibility is the Done status. Scrum and Kanban boards consider that right-most column (and the statuses assigned to that column) as the resolved column. Some board reports calculate reports based on this.

You might want to check them.

EmreT

[Mark Frear]

@Emre Toptancı _OBSS_ Thanks. So even though JSM has Cancelled, Resolved and Done as "done" fields, Only the resolution selection will trigger for the reporting?

So for solutions is it a. change internal process to stop using Done/cancelled or b. not use those reports?

[Emre Toptancı _OBSS_]

Hello @Mark Frear ,

Naturally, I don't know the details of your workflow and I don't know how much customization you made on your issue workflows. I am in no position to recommend a definite solution. I am just trying to point to the places that might be causing the unexpected behavior.

1. Jira issues have STATUS and RESOLUTION fields. Both are system fields. The Status field starts with a value something like Open or To Do. The status of the issues changes as your workflow progresses and usually ends on a status like Resolved, Closed, or Done. 
2. Resolution is a completely separate issue field. When an issue is first created, that field is empty. You are expected to set a value to the Resolution field when the issue is resolved in any way. You might set a constant value in your workflow to this field or you can use a transition screen in your workflow and make the user select a Resolution.
3. Most Jira reports (especially dashboard gadgets like created vs resolved chart) usually consider an issue resolved when a value is set to the Resolution field. The value of the Status field is completely irrelevant to these reports.
4. Default Jira workflows set a value to the Resolution field when the issue arrives at one of the Resolved, Closed, or Done statuses. (This behavior might have changed if you customized your workflow). If you are using the default workflows, the reports that depend on the resolution field should also work fine.

If you are seeing those inaccuracies in dashboard gadgets or project reports, I suggest you check that the resolution field is set correctly.

Also another point...

I had another look at the other community post you linked in your original question. That post is mostly about SLA reports. For SLA reports, it is another story.

Each SLA metric has its own definition and that definition includes when the SLA timer starts and when it stops.

An SLA timer might start (a) when the issue is created or (b) when it arrives at a specific status, etc.

An SLA timer might stop (a) when the issue arrives at a specific status, (b) someone comments on the issue, or (c) a value is set for the resolution field.

You can see the definitions for your SLA timers in the admin section of your JSM project. When you change the definition of an SLA timer, Jira can recalculate the SLA values for all issues in the project.

https://support.atlassian.com/jira-service-management-cloud/docs/create-service-level-agreements-slas/

One final note, it is a long shot but worth mentioning...

If you migrated to cloud from on-prem, the histories for issues migrated from the on-prem Jira are corrupted during the migration. This is a known migration bug. In that case, SLA results for those issues are going to be inaccurate. Issues created on the cloud should be fine.

Hope these help.

EmreT

[Emre Toptancı _OBSS_]

Sorry, posted as a new answer by accident. I was aiming to reply to the other thread.

I hope one of the moderators can remove this answer.