Knowledge Bases and Workflows - ACP-420 Study Session
This week we covered two, very different, topics!
Knowledge Bases
First we went over how to connect confluence to Jira. Connecting a knowledge base helps us support agents and customers. Customers will be served help desk articles as they put in tickets - this can result in them not needing to enter a ticket (called deflection), which allows agents to focus on more challenging requests. Agents, on the other hand, get in-Jira access to help Articles to solve tickets. This shortens the distance they need to go in order to get answers, and makes them more effective.
An important thing to keep in mind when linking confluence is it will only be as useful as the information in confluence. This means that if your information isn't organized, or is missing, it won't be very helpful!
Project admins can control which space(s) are linked, as well as which request types will be allowed to use articles. You can optionally filter content by label - for example only allowing article with “google-account” to appear under “Google account help” requests. Once it’s setup, articles will be displayed to customers as they enter tickets, allowing them to self-serve and preventing the need for a ticket entirely.
Once confluence is linked agents can also do things like categorize and label them, but also add new articles (assuming access is setup properly). Personally I find this to be incredibly helpful as agents will constantly be finding out new things that should be documented, and having a way to quickly add that to your KB is critical. Giving agents the ability to organize content as they see fit is also very useful as they may have slightly different needs or perspectives than other groups. Each space can categorize and label articles, allowing each group to decide how to best organize things. Agents also have the ability to search for articles directly from a ticket - this makes it much easier to use as they don’t have to dig around in menus and can instead quickly find what they need.
Workflows
Workflows are the series of stages a work item moves through in Jira. They represent the status of any given work item - for example “in progress”, “blocked” or “pending approval”. They're comprised of a few things, but before we dig into those we need to consider how they differ between team and company managed projects.
Team Managed Workflows
Team managed project admins can edit their workflows at any time, and the workflow is tied to a request type - not to an issue type This means they can't be shared across projects, but on the plus side it means admins can easily adjust things. Team managed projects do have some limitations (like no transition screens), but otherwise function similarly to company managed projects.
Company Managed Workflows
Company managed projects have their workflows tied to workflow schemes. These allow Jira admins to define a workflow across multiple projects, easily allowing them to scale operations and manage things. This means company managed project admins can't change their workflows, however, it does mean that it is much easier to manage workflows across an organization.
Company workflows also have some more options and features that are not available to team-managed projects.
Workflow Parts
Status - this is the status of the work item. They can be broken into three basic categories - to do, in progress and done. Note that status indicates where in the workflow something is - not how it is completed. Instead company managed projects have a resolution, which describes how the ticket was resolved. Resolutions are. A global setting and typical examples include won't do, done and duplicate.
Transitions - transitions are how issues move between statuses. A global transition allows any issue to move to a particular status, but more commonly custom transitions are used to control the flow of work. For example you ight not allow a ticket to move from open to done, instead it first must be in in progress.
Conditions - Conditions let you have specific criteria that must be met before a transition can be used. For example a specific person must have approved it, or a specific field is filled in.
Triggers - Automatically transition work items based on events - e.g. code commit it bit bucket.
Validatiors - validators can be used to ensure work items meet specific criteria before they're transitioned. For example you could require specific fields are filled in, or specific users are triggering the transition. These gives teams additional ways to enforce how tickets move, although they can be frustrating if teams don't know they're there.
Post Functions - post functions do something after the work item transitions. For example they can be used to clear the resolution when a ticket is reopened.
Properties - Properties allow more in-depth configuration of your workflow. They support other features and let you do things like restrict what someone can do in a specific status, or which resolutions are available.
We didn't get through all the workflow material, but we'll pick right back up with it during our next session after TEAM25 on April 14th!
