Services, SLAs, and Permissions - ACP-420 Jira Service Projects study session #4

Study session 4 is in the books! We covered three topics (detailed below), and will pickup with permissions next week since we ran out of time.

Next Week (Session #5)

IMPORTANT - Daylight savings ends (or begins? Not 100% sure how this works) this weekend. Please double check the time as it may shift by an hour.

Session #5 will pickup where #4 left off with permissions. Then we’ll get into:

1. Roles

2. Adding agents and customers

3. Team-managed permissions

4. Issue types, fields, screens in Company-Managed projects

What did we cover

• Features

  Project admins are able to turn on/off individual features within a Jira service management project. For example, if your group doesn’t use Services, just click the rocker to disable it. This has a number of benefits, but mainly it won’t clutter up your screen and it won’t confuse users with things they don’t need.

  That said, it can be frustrating if something is missing and you don’t know why!

• Services

  Services are things your team provides or supports. Some examples include databases, APIs and servers. Services can be grouped into Tiers, with Tier 1 being the most critical, and Tier 4 being least critical (e.g. folks won’t realize it’s offline). Services can also be linked to other services, for example, your website may depend on an API to work.

  Adding services to Jira service management lets your team more easily manage them as they can easily see what services there are, what tickets impact which ones, and how they relate.

  For example if the website is offline, you can easily see it is dependent on a specific server, and what issues impact that server.

• Service Level Agreements (SLAs)

  Service Level Agreements (SLAs) are agreements teams with with h customer groups on how quickly something is addressed. For example you might agree an account reset should be done inside two hours, or a server outage will be worked on continuously until it's solved.

  Jira service management allows us to define any number of SLAs, each of which can have different goals and different time targets. The tickets impacted by any given SLA can be defined by JQL, which means basically any grouping of ticket can be targeted. Within that you can break down specific time targets (how long someone has to meet the goal).

  SLAs also contain conditions, or rules when they start, pause and stop running. Typically SLAs begin when a ticket is created, however, this can be tied to some actions (assignment, comment, etc). Pausing an SLA is useful when the team is blocked (commonly info this when I'm waiting for the customer to reply). Stopping an SLA typically happens when a ticket is closed, but could also happen when a specific status is met or action taken.

  Finally, SLAs have calendars, which tell it which day(s) and time (s) to be counting down and a group can have any number of calendars. For example your 'account' tickets may use a 9-5 calendar while your 'outage' tickets may use a 24/7 calendar.

  Regardless of your initial setup I highly recommend making time on a regular basis (e.g. quarterly) to review SLAs and ensure they still meet your needs.

• Permissions

  We didn't get all the way through permissions but I'd highly recommend spending extra time here. Not only do I think it will show up on the exam, it's a common problem I run into in 'the wild', so the more we understand about how permissions work, the easier we can make others lives.

  There's 4 levels of permission, org, product, project and issue.

  • Org - access to your orgs entire instance. Allows control of things like admin, @mentioning and others.

  • Product - ability to control access to a product (e.g. Jira service management)

  • Project - ability to manage and control a project. This is typically the highest level of access I've had and allows things like modifying request types, changing rules, and managing SLAs. 

  • Issue - it is possible to restrict access to issues. Typically I prefer not to do this as it complicates things, but it can be necessary (e.g. for HR tickets).

Study tip

Keep Jira up on another screen or yab and switch into it to practice as you study. This will help cement ideas and remember things better. 

FAQ

1. Do services have to be linked to a physical thing?

   1. No! Services can be a physical thing, like a server, but are also typically non-physical things like API, websites etc.

2.     What is camel case?

   1. A way to notate fields and other information without spaces. (many systems don't allow spaces in names). Typically the first letter is lower case, and the letters of new words are upper. Examples:

   2. jiraServiceManagement

   3. pronounceJQLLikeJayquill (ok, that ones silly)

3.    Can SLA's be tied to Issuetypes or just Request types?
   

   1. Either! SLA's can be tied to any filter you can describe with JQL - so you can define a JQL query to pull tickets by either request, or issue, type... or almost anything else.

4. Can you use Atlassian Intelligence to build SLAs?

   1. Not yet :(

5. Can we prepare ourselves in just a month for the exam?

   1. In general I wouldn't recommend it as there can be a lot to learn! That said, if you can dedicate a lot of time to studying, practicing and understanding this can be possible. Personally I like to take 2-3 months to prep, but others can go faster.

6.  Why am I limited to a single workflow per request type?

   1. On a technical level I believe Atlassian limited this to ensure tickets know which path to follow.

   2. On a process level this makes also makes sense as any give type of request should follow the same workflow - e.g. under what circumstance would a "password reset" require an entirely different set of statuses? If it does, it's likely a different request.