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

[Dirk Ronsmans]

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?

[Patricia Francezi]

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. 

imho.

[Dirk Ronsmans]

@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.

[Patricia Francezi]

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....