ITSM Projects & Portal Configuration | ACP-420
A major use case for Jira is to support IT Service Management teams
This week we’re digging into how to configure Jira Service Management (JSM) to support ITSM (IT Service Management) and how to configure the customer Portal.
Whats ITSM?
At a high level ITSM is how information technology teams set themselves up to support their customers. This includes everything from determining what processes they need to use, to how they’ll setup Jira to what types of tickets they’ll take to what SLA’s they’ll have. I find this to be one of the more common use-cases for Jira, although groups may not call it “ITSM”.
The Portal
Each Jira Service Management project has a portal that allows customers to put in tickets. Typically this portal is only available for internal customers via a specific link - but can be exposed to external customers as well. The portal contains request types, which may be put into groups. For example anything related to requesting or fixing hardware could be found under a “Hardware” group (note that request types can be added to multiple groups!).
Portals can be grouped into Help Desks. By default every instance has a single help desk which contains every portal, however, you can create additional help desks as needed. The help desk is intended to be the one place everyone knows to go to when they need help as typing something into its search bar will bring up things like:
Confluence content that related to the search
Portals that relate to the search
Specific request types that relate to the search
It’s important to keep in mind that the help desk’s ability to search is limited by how well the underlying content/information is setup. For example, if your Confluence space it’s structures well and articles don’t have relevant titles customers won’t find content easily.
Both portals and help desks can be branded (the first by project admins, the second by Jira admins). THis is something I highly recommend doing for every portal as aligning the look and feel with your corporate brand makes it easier for folks to use it (after all if they find a portal that has different logos and colours than they’re used to they may think they’re in the wrong spot).
Portals and help desks can also have announcements - basically a banner at the top that can be used to share information. Common examples include information on system outages, company events and other information that everyone should know. Project admins and Jira admins can edit announcements on the Portal and help desk, and you can optionally allow agents to update announcements at the portal level. Note you can’t specify which agent, any agent will be able to do this.
ITSM Support
The first thing any group should do when using Jira Service Management to support ITSM is to ensure they understand their internal processes and policies. Failing to do this will result in a setup in Jira Service Management that doesn’t quite fit - and will need to be rebuilt. Once that work is out of the way, however, Jira provides a number of features to support ITSM.
Request Types & Forms
Request types allow teams to tailor intake to specific things. Many IT teams will have a (relatively) fixed menu of what they support, which can be expressed as various request types. Depending on the teams need, these request types can be restricted (e.g. only VPs and above can use the “Executive Help” request type), or tweak to fit specific groups.
Forms allow groups to collect additional information on request types - and they don’t require a Jira admin to setup. They also offer a number of formatting features (similar to Confluence pages) which enable teams to create more appealing looking forms to solicit information. Forms can also be filled in after a ticket is submitted, allowing agents to collect additional information as the process continues.
One practical thing to be aware is that forms do not auto-expand on tickets. This means that when an agent opens a ticket, they won’t see the entire form. Instead they’ll get a line indicating there is a form that they’ll have to click on to use.
Notifications
Notifications are sent by Jira around specific events, for example, when a ticket is created. There are a number of default notifications that let folks know what is going on, however, it is always worth the time to take a look at them and adjust them as needed. This could include changing the terminology used to match your organization’s guidelines, or even adjusting the template (with HTML and CSS) to match your branding.
This seems like a small thing, but having tailored communications can have a huge impact on your customers, and their perception of your team.
Conclusion
The Portal is likely the first thing your customers interact with when using Jira Service Management - so make time to tailor it to your needs. Additionally, take time with your team to understand what they need to do, and what processes they need before you start setting up Jira Service Management and you’ll save yourself a lot of headache!
Check out the video below and hope to see you in a session soon!
Permissions and Roles | ACP-420 Jira Service Projects
Dive into permissions and roles!
Aren't time changes fun? Apologies to the folks who missed any/all of session 5 due to the time change... Luckily we have about 6 months before we get to do it again! (recording below if you missed out!)
Session 5 dug into permissions and roles. Personally I have to handle questions related to these topics on a weekly (sometimes daily) basis, so they are close to my heart. This also takes up 14% of the exam (but feels like half of my day sometimes!).
Check out the info below for more about what we covered, including the FAQ that folks had.
-
Before we get into how they work, you'll want to consider why you need them. It's very easy to dig in and start building roles or schemes. Resist the urge! Instead, step back and talk to your team and stakeholders about what is needed. I start by understanding the types of people who will be using Jira. Examples include agents, auditors, managers and the like. This is essentially building your list of roles, which will be useful when you start building.
Once you understand the groups you can determine what they need to do. For example, some groups may need the ability to respond to customers, while others should only be able to view tickets. This mapping process can feel arduous, but is an important step in understanding your teams needs.
This can take a while, but at the end you'll have a blueprint of what you'll go build. This makes it much much easier since all you'll have to do is push the right buttons - all the hard part (the thinking) is already done.
-
Permissions are layered, like an onion! On a day-to-day basis I regularly only interact with these at the Project level, however, as admins we need to understand what falls into each layer, and be ready to troubleshoot issues that can span levels.
Organization - At the top is the organization level. This layer control things like the ability to @mention, or access the instance.
Product - Next comes the product - e.g. Jira service management. This level mainly allows you to manage who can use the product in your org.
Project - Next is project level. This is where most folks will have access as it allows you to be a project admin. Here you can control things like roles, customer access and the like.
Issue - The last level is the issue layer. Typically I don't see this level being used as it adds more complexity and most of the time you don't need to lock issues. That said for environments with sensitive data (e.g. hr, finance etc) locking issues is important.
While there aren't 'gotcha' type questions on Atlassian exams, we do need to be careful and understand nuances to access. For example, 'assignable' and 'assignee' are both required permissions to be assigned a ticket (the first allows you to be assigned to a ticket, the second allows you to assign a ticket). Nuances like that are important for the exam, but also as a an admin to support our teams.
Some nuances we should keep in mind include:
Jira Admins are determined by who has access to the “jira-admins-(sitename)” group, or assigning a user to the Jira Admin product admin role
“browse users and groups” lets people @ mention users, select users from picker fields, share issues and see names. It does not prevent folks from assigning issues (I ran into this at work recently!)
“Browse projects” is the most important permission (according to Atlassian! :D) as it determines who can see a project and issues… without it you can’t see anything, regardless of your other permissions.
In order to edit due dates and rank issues you need both schedule issues AND Edit issues
Service project agents only applies if you’re in JSM
Some perms can be disabled globally like liking, watching and voting.
-
I think of roles as types of people that work in Jira. There are four roles that come with Jira, and we can't remove them - admin, agent, collaborator and customer.
Confusingly team and company managed projects have different names for them…for example 'agent' in team managed and 'service desk member' in company managed.
That said each role contains the appropriate permissions for those types of people. Agents, for example, can open and edit tickets. Collaborators can open, and post internal comments, but not edit. As an admin in a team managed project you can edit roles, but jna team.managed project you can't (unless you happen to be a Jira admin too).
We aren't, however, stuck with just the roles were given. We can create new ones. This may require a Jira admin, but once they're created project admins can assign them to people, which indirectly allows project admins to control permissions. These roles can be incredible useful in meeting needs of your team, which makes understanding what they need to do and why even more important.
Next week we'll get into, looking forward to seeing you there!
FAQs
Why are roles name differently in Team and Company managed projects?
I have no idea! It is a bit confusing though…
How can project admins manage permissions in Company-managed projects?
They can indirectly manage permissions by assigning Roles. This is where it’s important to have a good relationship with your Jira admin so they can partner with you to build Roles that make sense for your team.
Why is “schedule issues” necessary to re-order issues on a backlog board?
This is a great example of a non-intuitive thing we have to just know. From what I understand it has something to do with how Jira stores rank order information… does it make sense? not really… Do we need to know this to help folks? yup.
Check out the session recording here