Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Transition between teams: Service > Work > IT

I can only find topics from 2018 about this, but recently a lot has changed at Atlassian.


How should companies use Atlassian products in 2022 to transition work between teams and different Jira software products?

1) An idea is created inside Jira Service Management.
2) Then the Product team thinks about it and writes specifications on it in Jira Work Management
3) Then the Content writers add text for it inside Jira Work Management
4) It's planned and moved to Jira Software for development
5) IT needs an extra translation and asks it via Jira to the Content writers

On top of that I use Jira Delivery management to keep track of projects...
So that's one more step and one more Jira product to maintain...

But what should we do when moving between Jira products?
- Should we just create a new card in each project and link them?
- Should we convert them to an issue in another project?
- How do we keep the information inside the Service ticket update?

Should our content writers have a license then in Jira Software as well to be able to see those tickets and add the translations to it later on?


I'm a bit stuck on:
- which licenses which type of user needs (does everyone needs to have a jira software license to support IT?)
- which Jira product should which team need to use
- create a new ticket and link OR move a ticket to a new project/software?


Thank you.

1 comment

Ok, best thing you can do is stop moving issues around.  Moving an issue is a structural thing, hard to automate and clunky for the users.

The service management to other project is best done with the "create linked issue" function.  An agent can go "oh, hang on, this needs a developer", click the box and get a (prefilled with the JSM issue details) box for creating in another project.

You can do that from other projects as well if that might help.

But, once you've created that issue elsewhere, have a look at its lifecycle - does it really need to be represented in different projects, or could you just get each team who needs to see it to include it in their boards and backlogs when it's in a status that's their responsibility.

Can a work management user see the jira software issues?
If a developer needs one extra translation, how would he get it?

Yes, you can allow JWM users into Software projects.  They just won't be able to use the boards.

I created a general board, as the jvm board has no option to show the subtasks.
Does that mean our jvm users won't be able to see their own general board anymore of their own project?

No, the project board in JWM remains in place.

Is there any way to show the subtasks in the JVM board?


Log in or Sign up to comment