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

Service Request and Service Request with Approval, why the distinction?

Dirk Ronsmans Community Leader May 04, 2020

By default when setting up a JSD project several issue types are added.

2 of them are 

  • Service Request
  • Service Request with Approval

both workflows are very similar but with an added approval step in one of them ofcourse.

Now my question is why? Why is this split up in to 2 different issue types? What is the added value?

Imho, you could perfectly have a single issue type with a optional approval step.

This optional step could however be enforced by adding a flag on the request type (using a condition) and/or an automation (especially now with the new automation on Cloud) to set it automatically.

If however approval is not enforced (through a flag or automation) the SPOC can still decide whether to push it to approval or to set it to "work in progress" immediately.




Your thoughts?

1 comment

I think you may need other N issuetype workflows that define your business.

A workflow maps a work process, and I always avoid to request human decisions, as the agent may not decide or just forget to request for approval. 

For the customer perspective it leds to frustration, more time with issue open, poor feedback about your service and so on. 

Automation is great, but a clear process, less dependency of admins to control the process itself, is better. 


Dirk Ronsmans Community Leader May 05, 2020

@Patricia Francezi ,

True but from a process point of view it doesn't make sense to have a whole different workflow for a 99% similar issue type.

This just adds more overhead and administration imo when you want to administer everything beyond the approval step.

While approval should not be the choice of the agent it does help when for example a user created a non-standard request which you would like to have approved or when an incorrect request was created and you don't want too much hassle in moving it from one issue type to another.

I feel like the approval itself could very easily be managed through the request type itself or a flag/custom field/link to a CMDB.

Thus allowing for a single workflow with just a minor exception path when needed.

well, i once put approvals in a service request (normal) issue type, to run with automation after ticket being created from email. completed the approval information with automation, requested for approval, etc. 

its flexibility. I think you can design the way you need, but for begginers, or for cloud customers using a template, without knowing how to achieve an issue type with approvals, its really good to have a template to just use in the first attempt. 

when you grow as Admin, have a good understanding of proccess, advanced workflow configurations, etc, we are able to design it for almost anything we want to.

Automation does the trick too. Reducing the templates would complex the tool for new users, right? 

And its a self service tool (as SaaS should be), low price for its capabilities. 

I dont think Atlassian wants to reduce its news users to high skilled admins, or having a long learning path to be able to sell it. 

I use to say that, i.e Next-gen projects are products inside the product. The target audience: non tech savy users.... different business, and so on.... 


Log in or Sign up to comment

Atlassian Community Events