Atlassian JIRA has two different places to setup an email connection: incoming and outgoing. This probably goes without saying, but let me briefly define these for you:
- Incoming: This is where you add one or more email server connections for incoming email. This email will be used to create JIRA issues, comments, and potentially users.
- Outgoing: This is where you add one email server for sending email from JIRA. These will typically be notifications, such as that an issue was created, assigned, or commented on. JIRA can only have one outgoing email connection.
At first glance, you might think, “OK, we already have email@example.com, so let’s use that for JIRA.” And you plug that in for incoming and outgoing email. But that can cause some problems.
In JIRA, we have three options when dealing with permissions:
For those of us who have been doing this for a while, we have learned that there really is a right way and wrong way of working with users and groups. While working on the JIRA certification exam, however, I discovered that there is no published documentation on the subject. So consider this a permissions best practice article from someone who helped write the certification.
As a tl;dr, you should use roles whenever possible. With that established, I’ll go into a bit more detail.
One of the most challenging things to teach people is business analysis. BA work is interdisciplinary, combining skills from a variety of backgrounds, and you need to know both the technical tool being used as well as how to ask questions and be an active listener.
In this article I’m going to give you a few tips for how to map your business into JIRA. Thinking through these questions and talking with people in your organization will help you build the right thing the first time, which will save you a lot of trouble in the long run.
JIRA’s workflow engine provides a powerful tool for managing and monitoring the work that you and your teams are doing. By tracking the status of tasks, stories, epics, and initiatives, you can improve certainty, reduce or eliminate status update meetings, and build in automation and controls at each status transition. But when a company begins using JIRA for the first time, they sometimes make the mistake of over-complicating their workflow. You want to get fine-grained visibility into the status of work, but building a workflow with twenty or thirty statuses results in a workflow nobody wants to use. A better approach is to start with a simple workflow, and add statuses when you need them.
But how do you know when you will need a new status? I have a couple of rules that help me make workflows that people like to use, and when people enjoy using them, they’re more likely to keep the ticket updated, which means your data is more accurate and actually useful.
The basic configuration of JIRA Service Desk (JSD) is pretty easy. As long as you know JIRA Query Language (JQL) reasonably well, or you can use the basic search in JIRA before switching to Advanced to copy and paste the JQL you need, you can setup pretty much everything you need with little or no prior experience. Not much can be customized, and the interface is clean and simple.
That said, I’ve been digging into the nuance of JSD and learning a bit more about its inner workings. Atlassian hasn’t released the code to JSD, so we don’t have much visibility into why or how it does the things it does. This leads to questions and confusion, and in some cases, things simply not working as expected.
In the summer of 2015, I joined a group of other Atlassian Experts in San Francisco to design the blueprint for a JIRA Administrator certification, and I went back a month or two later to work on the blueprint for a Confluence Administrator certification. Atlassian has now announced these certifications, which means I can finally write a bit about them.