Workflow with 2 stages of review

[Melissa Kibrick]

Our process has 3 stages for review and feedback.

1. After a product document is complete, it is reviewed by the team supervisor first. Documents are often sent back and forth.
2. After that is complete, it moves to the product manager with another cycle of revisions. 
3. After a PM approval, it goes out to the client for approval. At this stage, if there are changes, the changes have to get approved from the beginning.

Currently, we don't represent stages 1 and 2 in JIRA. I need data on how much time these stages take and where documents are, and ultimately I want to make this more efficient. 

• Is there a more efficient way to build this process?
• Would the "Approvers" in JSM help?
• Is Approvers essentially a temporary Assignee?

[John Funk · Accepted solution]

Hi Melissa - Welcome to the Atlassian Community!

I would say that using the built-in approvals of JSM would be the route to go. As Dirk says, they will be a simple Approve or Decline, but I think that is all you are looking for - correct? And they could even approve via clicking on a button in email if they wanted. 

[Melissa Kibrick]

@John Funk our approvers are already full JIRA users. They are the documentation team lead and CIO. They give feedback to the original document writer. I'm trying to understand (and then explain) why the approval feature is better than a workflow like the one in my picture. 

[John Funk]

In that case it might not be since they have to touch the issue anyway to give feedback. It might be easier for them after leaving feedback to click Approve or Deny. And you can limit who can do that by putting them in the Approvers field for the issue. 

Otherwise, you will just have the appropriate transitions between the statuses like you have in your diagram. Not sure one is more right than the other. 

[Dirk Ronsmans]

Hey @Melissa Kibrick  and welcome to the community!

My first question would be "where are these documents managed?"

Is this a confluence page or are you creating an issue which gets sent back and forth? (JSM/JSW/JWM?)

An approver in JSM is not really a temporary assignee, it's separate from that. An issue will have someone as assignee but a certain step in the workflow will require an approver to move it along. They will have no power in the issue by default except saying approve/decline and a comment.

If you were to do this with Confluence you might also look at something like Comala workflows where you can assign a workflow to a page.

[Melissa Kibrick]

Thanks for the welcome. 

We are currently using Word documents attached to the issue in JWM, but I am solutioning and JSM and Confluence are not out of scope. 

[Melissa Kibrick]

@Dirk Ronsmans so are approvers appropriate for a feedback loop like this? Why use approvers rather than a full user for feedback loops? Is it so you can control the approvers and keep them out of the back end of JIRA?

[Dirk Ronsmans]

Hey @Melissa Kibrick ,

99% of the time using an approver instead of a full user is due to licensing. An approver can approve/decline by email or portal which defines them as a customer. 

if there is no need to have the approver in your system other than doing that approval/rejection they don't need to see your internal workings and/or consume a (costly) agent license.

IF however as you already mentioned in the answer from @John Funk  they are already a user it doesn't really matter whether they use the portal/email or the regular agent view.

Using the JSM approval mechanism tho (and thus the approvers field) still remains a valid choice as it would block the issue until approval/rejection.

So I feel for your use case you could just create a nice issuetype in a JSM project and take advantage of the approval mechanism from JSM.

Even if you then need to escalate it to a customer (external party) you could still trigger them to use the portal.

If however, this is your main reason for using Jira/JSM (being document management and approval) you might just be better of using a purpose build solution for this (Acrobat's platform?) or integration that process in to a Confluence instance with for example Comala workflows.

If it's an extra thing and you already use Jira for other processes it won't hurt to give it a try. Keep in mind tho that it's not the main function/use-case of JSM so don't judge the product for something it wasn't really intended to be used for :)