Configuring Fields in Company & Team Projects | ACP-420 Jira Service Projects Study Session #7
Learn to configure issues and notifications in Jira Service Management
This week we continued our exploration of configuration, focusing on issues/work items and request Types, and this is another area that project admins will have a split experience in.
Team-Managed Projects
Team managed project admins can do basically anything they want in terms of issue type setup (note that technically there are only request Types in team managed). This is good for smaller teams, or in cases where a project is a one-off. Not having to go through a Jira admin and modify schemes (or add new ones) is a massive time-saver, and also frees up the Jira admins to handle bigger, more complex challenges. That said, it’s also a bad thing, as you might quickly end up with multiple team-managed projects floating around that all require administration… and due to how they work there’s no single way to manage them all.
Team managed project admins can, however, add new request Types at any time. This gives them a ton of flexibility to quickly spin up new request types on demand. They can also make any changes they want to the fields and workflow (well dig into these next week) they want to. This includes recording fields as displayed to the agent (the issue view) and the customer (request view). Company-managed project admins can do this as well, however, it is important to note that these are spread across different tabs (“Request Form” and “issue view”) in company-managed projects, but they’re on a single screen in a team-managed project.
Company-Managed Projects
Company managed project admins are much more limited in terms of what they can change. They can manage request types (including making new ones), but can't make new issue types, add fields, change screens or modify workflows. Also, any request type they create has to be linked to an underlying issue-type that’s available to the project (via the issue type scheme). This, in turn, limits the available fields to what’s connected to those issues types. This makes them entirely dependent on a Jira admin to help with updates. (Although they can't make these changes, understanding what is needed is very helpful as it makes it easier to file a request and work with a Jira admin to make those changes).
Company managed project admins can, however, control what fields are displayed on the request (as long as they're available on the underlying issues). They can also change the display name (what a customer sees) to make the experience a bit easier. They can also change the display name of workflow statuses, which seems like a small thing, but can have a bit impact on someone's experience.
Next week well pick up with emailed requests and then dig into knowledge bases and workflow setup! After that there's a week break for TEAM25 (if you're going let me know, I'd love to connect there!).
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
-
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 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.
-
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
Why would anyone use a Team Managed project?
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).
Why would someone NOT use a team-managed project?
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.
What is a “Jira-ism”?
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
Where can I get a recording of the sessions?
When I go into Project Settings why does “request type” not appear?
Request types only exist in Service projects, so you’re likely in a Business or Software project if you don’t see Request tyeps
What is a PICNIC?
Problem In Chair, Not In Computer
(Note - this won’t be on the exam!)
Why would I hide a request type from the portal?
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.
Why should I bother changing the request type icon?
The icon helps differentiate request types and makes the customer experience a bit better
It also makes it easier for agents and admins to differentiate tickets easily