Building a Department-Based Procurement Process in Jira Service Management

[#1]

The other day, I was in a job interview where the company wanted to have someone, who can set up a procurement process in Jira. I told them I could do this, but was also excited to prove to my self it the next day. It took me one day to build a MVP, which showcases the use of

• Atlassian user groups,
• Assets,
• Approvers,
• Workflow features, and
• Automations/Flows

In this article, I’ll walk you through the solution without documenting every click. Atlassian Cloud changes regularly, so I’ll focus on the concepts and configuration rather than UI details that may soon look different.

The scenario

Let's say Emma is working in the company's marketing department and needs more paper. Before her order goes to the procurement department, she needs Olivia's permission. Olivia is the manager of the marketing department. Once Olivia approves the order it goes to Mason, who will find the best vendor and place the order there. The workflow might look like this:

But wait, those are things that somebody DOES, not that something IS, so I better use this:

Of course, I also needed to build the declined path, and the resolved state:

By using default statuses I got the following workflow:

That was the final workflow. It is somewhat simplified, but will suffice. 

Users and Groups

Atlassian provides free development sites for its cloud products. Go to http://go.atlassian.com/about-cloud-dev-instance and you'll get a site with five free users (but only one agent 😑). I already had one and I wanted to build the procurement workflow into that site.

So I invented Emma, Olivia and Mason, gave them a face, a nice avatar, and an Atlassian account. As email addresses I used my own and added +emma, +olivia and +mason before the @. So Atlassian would treat them as individual addresses, while there was only one inbox. Inviting them onto my new site worked like a charm.

I added the three new users into the Atlassian user group jira-users-site. Emma and Olivia also got into jira-user-marketing-site and Mason into jira-user-procurement-site.

Those groups act as the single source of truth, so it allowed me to set up the procurement space access without any personal accounts:

I also used those groups for Assets relationships, and the departments users can select in the portal, as you'll see later.

Assets

At first I wanted to have Assets schemas for departments, employees, and roles and link them all together. But as it turned out I just need departments. Those departments have one manager and multiple members. The manager for Marketing is Olivia and the members are all in the Atlassian user group jira-user-marketing-site. Hooray for groups! 

In a real environment I would have put Olivia in a group called jira-managers-marketing-site and use it here, but decided against it, so Assets looked a bit fancier.

Space, Work Item, Request type, and Field

Next I configured the procurement space. It is a JSM space, where Emma can submit her request for more paper. I created a new work item Order and made it the only work type in the procurement space. I also created a new request type and a custom field Department, which references Assets objects: objectType = "Department" AND Active = true

I also added the filter work item scope "Member Group" HAVING user("currentReporter()"), so Emma can only select the marketing department.

Please take a moment to appreciate this beauty. Whenever a new coworker is added, us Jira admins have only to put that coworker in the user group(s) of their department(s). By this, they are member of the space, linked in Assets, and can order stuff for their department.

Workflow and Approval

I set up an automation which is triggered, whenever a new request is created. It looks for the selected department and asks Assets for its manager:

This manager is populated to the system field Approvers. This Approvers field is used in JSM's native approval process.

So I built the workflow mentioned above.

I implemented JSM's native approval process into the state Waiting for approval. As the Approvers field is already populated with the department's manager, I just needed to select the approve and decline transitions.

I didn't forget to put in the appropriate resolutions in the transitions leading to Canceled and Resolved, to ensure that Jira reports and filters recognize those requests as completed.

Customer Communication

Next I did some improvements regarding customer communication. So a validator for Due date was necessary in the transition form In progress to Pending, but putting in the expected delivery date shouldn't be a problem for Mason.

Then I set up automations for every transition, to show the customer where we stand in the procurement process and what to expect next. I did it as comments, but feel free to implement any channel your company prefers.

Finally, I set up a scheduled automation that runs once a day and searches for requests that are at least one day beyond their due date and have not been completed:

By now, this looks good enough. The model can grow from here, with possible extensions like

• deputy approvers,
• cost centers,
• value-based approval levels,
• supplier objects,
• purchase-order numbers,
• SLAs, and
• ERP integration.

But the core structure can remain the same. Testing looks fine and I hope the interviewer assesses my skills correctly. This is my first article. If you liked it, feel free to leave a thumbs-up. I’ve heard that every thumbs-up brings me one step closer to Atlassian swag. 😉

[s_gridnevskii]

This solution has many features of our procurement system. But we also have approval from team lead of requestor (just for the sanity reasons, to not let people order things they don't need). And also we have budgets. If order is within budget limit for the month it is approved by dep head, if it is not budget is reviewed and approved by CEO.

By now we have more than 20000 invoice requests in our system. We are extending it now by adding ability to send invoice in PDF attachment to a dedicated email address. AI agent extracts financial info from PDF file and adds it to the form which is verified and approved by dep head.

We also integrated business trips (flights and hotel payments). Employee fills destination and duration of event and HRs order tickets, then send invoice for payment to finance team.

[Karsten Gutjahr]

@s_gridnevskii that sounds like a reasonable thing to do. Do you already have that workflow in Jira?

[s_gridnevskii]

@Karsten Gutjahr yes, for about 2 years now. In fact we did a lot of services like this one, e.g. Onboarding, Access Management and so on. Our portal already has 11 spaces and keeps growing. Even if team does not do actual work in Service Desk project we collect approvals there and then copy request to Jira project with all approvals using service account. This help us to secure access to internal Jira projects (only team members have access) and reduce costs on agent licenses.

[zoltanersek _outpostlabs_dev_]

Great first article! 

I really like that you focused on the architecture and design decisions rather than a click-by-click tutorial. Those tend to age much better as Cloud evolves.

[Dave Rosenlund _Trundl_]

Nice work, @Karsten Gutjahr 👍

[Craig Williams]

Thank you! We are pleasantly surprised to learn about the filtering by the current reporter. Thank you for that nugget!!

[Karsten Gutjahr]

@Craig Williams, I did expect that this article might be helpful to someone in the future, but I totally didn't expect that to be on the first day! Thank you for your recognition. 🤗

[s_gridnevskii]

@Craig Williams we definetely need more examples in Service Desk documentation. I also find gems from time to time that help me do things that I did not even know are possible. Especially for asset fields filters and placeholders.