I don't seem to be able to find a manual from Atlassian about "How to use the ITSM template?".
What I'm looking for is like a 'best practices guide' which explains how Atlassian sees the usage of the fields and workflows in their ITSM template. There are of course things that speak for themselves, but there should be some document somewhere that shows Atlassians vision/idea on usage of the ITSM template.
For example: for an 'incident' request, which fields should contain which data and when to transition to which other state?
Hi @Erik Vanderstraeten ,
You might be interested in their ITSM Guide. I don't believe it has answers to specific questions such as "what is the use case for field X", but rather it speaks to why practices are shaped a certain way and what should be gathered from stakeholders to create a working process.
For your example questions:
>Custom field "affected hardware" - is it the intention that we link this to e.g. Insight?
Flexible depending on what you need. I don't actually have this field in my JSM/Insight instance so I'm not positive it's OOTB, but you can create custom Insight fields to display assets/objects for what is important to your business/services
>A service request starts in "waiting for support". I assume you put it 'in progress' as soon as enough information has been gathered to start working on it.
Typically yes, there may be some OOTB SLAs tied to your issue that do not count down when an issue is out of your control. This is why the back and forth between Customer <> Agent statuses are helpful, and when enough information is gathered, the SLA can accurately reflect how long the ticket has really been "worked on".
>What is the difference between the "waiting for customer" and "pending" with pending reason "more info required" then?
I typically see WfC as gathering more information related to the request, while Pending reflects that the issue is not being actively worked on ( blocked by third-party, on hold for business reasons, etc.) Again- flexible based on your business requirements.
>By default the customer seems to be able to escalate a request (status 'escalated'). Should we make a difference between a customer that wants more attention for his case and a 1st line support agent that needs help from a 2nd line agent?
The Escalated status by itself usually does not do much OOTB. You can leave it as is to allow customers the option to request "better" service, and have it display in different queues/notify teams from the status change. If simply wanting more support from a 2nd line agent, perhaps consider reassigning the issue, tagging users, notifying the team/group interally.
>Understanding the differences in the different workflows (incidents, service request, changes, problems...) why doesn't the incident workflow have the "waiting for support" <> "waiting for customer" states?
The core ITIL practices are described in the guide I linked above, Atlassian also has resources online for best practices for each.
>What to use the 'product categorization' and 'operational categorization' for?
Product: Define the type of service/object resolutions for this issue apply to
Organizational: Specification for what this issue/request relates to
Hi @Michael Andolfatto ,
Thanks a lot for your helpful and extensive response!
I just noticed there is some detailed documentation available as per my request:
I just hit it by accident. Will look for similar pages for the other ITIL processes too.
On October 20, 2021, Atlassian published a security advisory for Jira Service Management. The full advisory is available at this link. We've seen a number of questions already asking for...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events