You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Our process has 3 stages for review and feedback.
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.
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.
@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.
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.
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.
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 :)