We're recently released experience updates to Journeys in Jira Service Management that make it easier to monitor and manage active journeys and access journey-related context directly from work items.
Journeys allow teams to design, automate, and track structured employee experiences all in the same place where service work already happens.
View active journeys
You can now view a table of work items that are parents of journeys currently executing in Jira Service Management. This new page helps you track and manage active journeys more efficiently by providing a centralized view of their parent work items.
To access the active journeys table:
Go to your service space.
Select Journeys from the space navigation on the left.
Select the Active tab to view the table of work items.
Journey component on work item view
Work items that are parents of a journey now surface journey-related context directly within the issue view. This means your team can see which journey is associated with a work item without having to navigate away - keeping the right information close to where the work is being done.
You may need to republish an exisiting journey to view the new journey component on the work item.
Share your feedback in the comments below!
Kind regards,
Gemma Aldrich
Product Manager, Jira Service Management
Thanks @Dave Rosenlund _Trundl_!
Thanks @Brita Moorus !
Great to see Journeys becoming more integrated into the work item experience.
Thanks @zoltanersek _outpostlabs_dev_ appreciate your feedback!
Hi @Gemma Thanks for sharing.
I have the following questions:
@Gemma I'm with everyone else here in appreciating the excellent work here. A few quick follow-up questions:
This is a nice QoL update to Journeys, and I'm here for it.
There are some other things we would absolutely want to see before we start using Journeys.
1. Every time a Journey is updated a new automation rule is created.
With multiple Journeys and small tweaks here and there, we'll end up with an annoying recurring cleanup-task, or drown in disabled automation rules.
Not the end of the world, but absolutely some nonsense we shouldn't have to deal with in 2026.
2. Branching.
An onboarding for example. A new hire may need access to multiple IT systems.
The Onboarding work item has a multi-select field for systems the new hire needs access to.
A For Each branch looking at the multi-select field and creates an access request for each system selected.
Since Journeys seems to be basically Automation with a different UI, I imagine this is possible.
3. The Actor on the underlying automation rule is the user who created the Journey.
So if I configure an Onboarding Journey for our organization, it'll look like I'm the one hiring everyone.
And since editing the underlying automation rule does not actually change anything in the Journey, I can't just change the actor. I tried.
4. The underlying automation rule can be edited, but it won't actually do anything.
Then why can it be edited? Or why can it be edited by humans?
It'd be a better experience if the automation rule was read-only.
Nice one - do Journeys accept Asset fields already?
Recommended Learning For You
Level up your skills with Atlassian learning
Learning Path
Get the most out of Jira Service Management
Start with basic Jira Service Management terms and navigation. Then, discover how to solve customer problems efficiently.
Learning Path
Adopt ITSM practices to deliver exceptional service
Learn IT service management principles and configure Jira Service Management to implement ITSM processes.
Atlassian Certified Associate
Jira Service Management Agent Essentials certification
Prove you know what’s essential to providing efficient and resolution-focused service in Jira Service Management.