Project Type Showdown, Request Types and Queues : ACP-420 Study Session #3

ACP-420 session three is in the books (embedded at the bottom of this page too)! We picked up right where we left off with team vs company managed projects, and got through setting up queues (more specifics on those topics below).

Study Tip

If you're in my sessions have a Jira service management instance up and follow along live. This will let you see the concept, but also uncover questions you may have and ask them live.

Topics

• Team vs Company Managed Projects

  These two project types certainly bring up conversation!  While both offer the ability to collect and manage tickets , they differ quite a bit on the management side.

  Team managed projects let the project admin adjust almost everything. You can add request Types, change workflows, add fields and more. This gives smaller, less technical, teams a lot of flexibility.

  Company managed project, on the other hand, have a wider array of features, but limit what a project admin can do. You can still make request Types, but can't modify workflows, fields, screens, notifications or access. This is because company managed projects use schemas, or shared configurations.  Schemes let an orgnaization share configurations across projects, vastly simplifying administration.

  There is some debate about whether groups should ever use team managed projects (ill dig more into this in a future blog post), but for the ACP-420 we are expected to know the differences.

• Request Types

  Request Types are customer facing forms that let customers out in tickets. Project admins can set them up and modify them as needed, including things like hiding fields, grouping in the portal and having more customer friendly field names.

  • In a company managed project these are all tied to an issue type, which provides the workflow for the request type.

  • In a team managed project there is no issue type, so each request type has its own workflow, fields and more.

• Queues

  If request Types are how customers enter tickets, queues are (one of) the main ways agents interact with them. Queues are essentially saved searches that project admins manage to guide agents on which tickets should be solved.

  Agents can select queues to view, but only project admins can edit queues. This means that we, as admins, need to take time and effort to craft queues that best support our teams. Admins can do things like

  * Define the tickets in the queue - this is done via Jira search (basic or jql) and can be refined at any time

  * Define what columns are displayed and in what order - this allows admins to tailor what information is easily access access

  Queues can be grouped into 'priority queues', basically groupings project admins select. This helps further guide agents by helping them work in one spot and not having to jump around between parts of Jira.

Questions

1. Why would anyone use a Team Managed project?

   1. It gives teams more local control of their project and removes reliance on a Jira admin (something many company's don't have, or have in limited supply).

2. Why would someone NOT use a team-managed project?

   1. Eventually many teams outgrow a team-managed project or need more support so they need to be converted. This takes time and effort, which can be avoided if you just start in a Company-managed project.

3. What is a “Jira-ism”?

   1. Anything that makes you hang your head in disappointment over decisions Atlassian makes that common sense would tell you could have been implemented in a much better way

4. Where can I get a recording of the sessions?

   1. Here!

5. When I go into Project Settings why does “request type” not appear?

   1. Request types only exist in Service projects, so you’re likely in a Business or Software project if you don’t see Request tyeps

6. What is a PICNIC?

   1. Problem In Chair, Not In Computer

   2. (Note - this won’t be on the exam!)

7. Why would I hide a request type from the portal?

   1. I do this to let my agents enter specific types of tickets but not customers, for example “hardware request” could be something only agents can enter after they think new hardware is needed.

8. Why should I bother changing the request type icon?

   1. The icon helps differentiate request types and makes the customer experience a bit better

   2. It also makes it easier for agents and admins to differentiate tickets easily