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.
I am very pleased to announce that the case study I mentioned in my last post has gone live.
CH particularly commends Adaptavist for understanding its needs in a business context. “We were very much looking for that holistic picture back from your team,” says Irene, “and the value of working with you guys is you helped configure a tool that makes it very easy for our people. The tools support them in being as efficient as possible.”
Last but not least, Adaptavist helps CH work more efficiently. Preston comments, “The question is raised, ‘Why don’t we get a JIRA engineer in-house?’ But you guys have such expertise in Atlassian products, and can build with such clarity, that it’s much more efficient to work with your experts than for us to try and build that expertise in depth ourselves. Your knowledge just makes our development process much more efficient.”
See the full case study page at Empowering people and processes for Collective Health or read the full case study in PDF.
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.