I'm hoping for some help developing a logic for a transition/step in a fairly complex workflow used to track department hiring requests/candidates. I've looked around and could not find anything similar to my request given the links and custom logic. I will give as much info as possible while staying concise: Primary problem: Need workflow step / transition logic for an issue needing multiple approvals by different people (determined by the issue links) before transitioning to a specific step. Background: Project for hiring/tracking in a department. Two issue types: Hiring Request, Candidate Candidate Workflow: RCRT Candidate Snip.PNG Issue links: one valid issue link is set up for with "is a candidate for" and "has candidates". One hiring request can have multiple candidates at a time. Also, a candidate could be a fit (is a candidate for) multiple hiring requests. Detailed Problem: The main problem is transitioning a candidate from "Pending Hiring Manager Review" to "Pending Phone Interview". I'd like a way to have the following logic implemented: * If any Hiring Manager (Requester field of the 'Hiring Request' which the 'Candidate' is linked to) approves a candidate to phone interview, transition the candidate to the "Pending Phone Interview" Status. * When above (1) happens, transition the 'Hiring Request' Item also to the 'Interviewing' status (this one seems easy enough with a post function) * **Difficult** If a Hiring Manager (Requester field of the 'Hiring Request' which a 'Candidate' is linked to) rejects a candidate, wait until other Hiring Managers who are linked to the candidate also reject him before moving. Example: Candidate A is a candidate for hiring requests X, Y, and Z. Hiring Managers for X and Y reject him. I do not want him to go to rejected status yet (as that would kick off a rejection notification). Once hiring manager Z rejects him (and we double check he has not been added to other hiring requests, besides X, Y, Z) then all Managers have rejected him and he can be moved to rjected status.* My thoughts on above: Would this be better done by 'de-linking' the candidate from the hiring request if a rejection occurs? Then, when a rejection occurs, we could check if the candidate has any other outstanding (besides his current rejection) hiring requests attached, and if not, move him to rejected. * If this is done strictly from the candidate item point of view - we'd need some logic to track all the hiring managers responses attached the candidate (maybe with an extra hidden or non-modifiable field?) I greatly appreciate any help or suggestions on how to make this work. Thank you, RCRT Candidate Snip.PNG RCRT Structure.PNG

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Complex Workflow with Multiple Approvers, Issue links, Link specific triggers

Chris C3

I'm hoping for some help developing a logic for a transition/step in a fairly complex workflow used to track department hiring requests/candidates. I've looked around and could not find anything similar to my request given the links and custom logic. I will give as much info as possible while staying concise:

Primary problem: Need workflow step / transition logic for an issue needing multiple approvals by different people (determined by the issue links) before transitioning to a specific step.

Background: Project for hiring/tracking in a department.
Two issue types: Hiring Request, Candidate
Candidate Workflow: RCRT Candidate Snip.PNG

Issue links: one valid issue link is set up for with "is a candidate for" and "has candidates". One hiring request can have multiple candidates at a time. Also, a candidate could be a fit (is a candidate for) multiple hiring requests.

Detailed Problem: The main problem is transitioning a candidate from "Pending Hiring Manager Review" to "Pending Phone Interview". I'd like a way to have the following logic implemented:

If any Hiring Manager (Requester field of the 'Hiring Request' which the 'Candidate' is linked to) approves a candidate to phone interview, transition the candidate to the "Pending Phone Interview" Status.
When above (1) happens, transition the 'Hiring Request' Item also to the 'Interviewing' status (this one seems easy enough with a post function)
**Difficult** If a Hiring Manager (Requester field of the 'Hiring Request' which a 'Candidate' is linked to) rejects a candidate, wait until other Hiring Managers who are linked to the candidate also reject him before moving. Example: Candidate A is a candidate for hiring requests X, Y, and Z. Hiring Managers for X and Y reject him. I do not want him to go to rejected status yet (as that would kick off a rejection notification). Once hiring manager Z rejects him (and we double check he has not been added to other hiring requests, besides X, Y, Z) then all Managers have rejected him and he can be moved to rjected status.
1. My thoughts on above: Would this be better done by 'de-linking' the candidate from the hiring request if a rejection occurs? Then, when a rejection occurs, we could check if the candidate has any other outstanding (besides his current rejection) hiring requests attached, and if not, move him to rejected.
2. If this is done strictly from the candidate item point of view - we'd need some logic to track all the hiring managers responses attached the candidate (maybe with an extra hidden or non-modifiable field?)

I greatly appreciate any help or suggestions on how to make this work.

Thank you,

RCRT Candidate Snip.PNG

RCRT Structure.PNG

Accepted answers

Fidel Castro

I don't like the idea of delinking issues, since we are losing information. If a Candidate is applying for more than Hiring Request we shouldn't lose that information, even if the candidate is selected only for one of them.

A possible approach is this one:

We add two reflexive transitions at status Pending Hiring Manager Review in Candidate's workflow. Reflexive transitions have the same status as origin and destination, and therefore they don't change status. These 2 transitions are called Approve Candidate and Reject Candidate. When we trigger Reject Candidate transition a hidden text custom field called Rejections will be populated. This field contains a comma separated list of issue keys of the Hiring Request s that the Candidate has been rejected for.

If the Hiring Manager only have a Hiring Request linked to the Candidate he is approving or rejecting (this is the most probable case), he will not have to enter any information, otherwise a transition screen will be shown, asking the Hiring Manager to input the issue key of the Hiring Request he is approving or rejecting the Candidate for. We can do it adding not one, but two different reflexive transitions for approving and other two for rejecting a candidate. One is visible only in the case when there is more than one Hiring Request to the same candidate for the same Hiring Manager, and only this one will show the transition screen requiring the issue key of the Hiring Request. If the Hiring Manager doesn't have any Hiring Request with a Candidate he will not see any Approve Candidate and Reject Candidate transition.

If a Hiring Manager is rejecting a Candidate for the last of its pending Hiring Request, then the Candidate issue will be transitioned to Rejected status.

All this can be done using conditions, validations and post-functions of JIRA Workflow toolbox.

All comments

Nicolas Bourdages

Most of this looks possible using post-functions from the Misc. Workflow Extensions plugin. Post-functions to trigger transitions in linked issues will work well.

Your step 3 cannot be done only in a workflow. The manager responses are more like "votes" than actual transition calles. You might need custom fields for each of the rejecting managers. Your "Reject" transition should then have a validator that all these fields have a value (like checkboxes) before the transition is actually permissible. You might need some scripting to verify that the candidate doesn't have other links before though. There are voting plugins out there, maybe you should have a look. If the whole approval/rejection logic can be taken care of by a plugin, you'll simplify your workflow logic greatly.

Perhaps unlinking the candidate would work, but I feel that changing the link from "a candidate for" to "rejected for" would make more sense. That way, you keep a permanent record of who applied for what position.

All that being said, this is the first time I've encountered such precise needs to use JIRA for HR tasks. Did you look at other solutions, or specialized plugins? This one looks like it could do most of the hard work.

Doug Swartz

I developed a, sort of, similar workflow for an item with multiple work steps. I used a plugin called JIRA Workflow toolbox. Here's a design that might work:

Create a subtask of the candidate issue for each hiring request the candidate is being considered for. Link the subtask to the hiring request issue.
The subtask has a simple workflow Open to either Rejected or Approved for Phone interview.
Create a post function on the subtask issue type using the workflow toolbox to advance the parent candidate issue to phone Interview if a subtask moves to "Approved for Phone Interview".
Create another post function on the subtask issue type to move the parent candidate issue to rejected if the subtask triggering the post function is set to rejected and all of it's siblings are also set to rejected. I would probably use the toolbox JQL query condition post function for this.
If you need to keep anyone except the hiring manager from advancing a subtask, add a condition from the toolbox to hide the transition from everyone except the hiring manager (who is probably the assignee on the subtask)

There are other plugins which will help you do the same kind of thing. You could do it with the scripting plugins, although it would be a little more work. If you have absolutely no money for plugins, this approach is probably not reasonable for you.

Chris C3

Thank you for the response.

The number 3 is definitely the hardest part. I took a look at the herzum plugin linked. It looks like a nice/useful tool, but I'm not sure its capable of my specific request. I see it has having an option for holding transitions until the 'Requestor' approves, but I don't think it allows you to go as deep as 'hold until the requestor of all linked issues' for the item (as it seems to only allow static number of approvers per transition).

I believe the primary difficulty lies in how dynamic the number of approvers can be. Its not department 1 2 and 3 like most workflows. The candidate could be linked (and thus approved/rejected) by a dynamic number of approvers / hiring managers, as many as 6 in some cases. This makes me think the issue link checking logic may be a better solution, and your suggestion for 'is rejected by' is a great one!

Is it not possible to put validations on workflow transitions without the misc extensions plugin? Using links it seems the hiring manager would still need to go in to their hiring request issue item and manually remove the 'has candidate' link and change is to 'rejects candidate'. This couldn't easily be done from the Candidate issue item's point of view with a button as far as I can tell, as it would somehow have to know what the person logged modifying it's intent as far as open position is. It would have to be something like an approve/reject button next to their 'hiring request' issue link on the candidates actual page.

Similarly, I wonder if theres a way for the 'Hiring Request' Item to have a button specifically by the linked candidates area which the managers could use to just a hit a approve/reject button to kick off the transition for that specific linked candidate.

Fidel Castro

Hi Chris,

JIRA Workflow Toolbox can easily implement all three requirements with any approach you decide for these workflows. I'm the developer of that plugin, and will you all the details to implement the workflows using this add-on, once you decide the approach you will take.

You should take into account that a Hiring Manager can have more than one Hiring Request linked to a same Candidate, and for that reason when a he approves a Candidate to phone interview, he should also enter the Hiring Request the Candidate being approved for.

I find the approach proposed by Doug Swartz very good, since each subtask is linked to a Candidate for a particular Hiring Request.

If you decide to use the approach where issues are delinked dynamically, and relinked with another issue link type, it can also be done automatically by JIRA Workflow Toolbox using post-functions, this way your users don't have to do all that operations manually, avoiding any risk of mistakes. Anyway, I prefer the previous approach, since it's simpler and I think that it's more natural to use issue statuses to describe the situation of an issue, than using changing issue links.

For your requirement 3, which you find very complex, a validation can be easily implemented using Boolean condition with math, date-time or text-string terms , that will do exactly what you intend to do.

If you are interested, once you have all 2 or 3 (Candidate, Subtask and Hiring Request) designed, I will give you the boolean expression for implementing the validation.

Regards,

Fidel

Chris C3

Hi Fidel,

Thank you for the response. Your tool does look like it could be a valuable addition. Do you think there is any way to do the implementation without the creation of subtasks? We are using The Structure plugin with both issue types as top level. This allows our less technical (not heavy JIRA users) Hiring Managers to easily drag and drop a candidate into their position, and also to give a clear, easy visual representation of where we are all with all positions.
RCRT Structure.PNG
Right now dragging and dropping candidates creates a link with the job description and has them appear (sometimes multiple times if for diff positions) under the open position. So candidates can appear multiple times in the structure, but it is still the same single original candidate item (not a duplicate) as a subtask would be. This makes it easier for the user to clearly see the candidate info without having to go through multiple links (as it seems a subtask would require? One from job to subtask issue, and then another link from subtask to actual candidate item with the info). It is a many-to-many relationship. Wouldn't using the more strict subtasks lose some of this, or otherwise clutter the system with extra tasks?

Maybe I'm not understanding it correctly, as it is an approach I hadn't considered.

Also, hate to be that guy, but this system will not let me respond more than twice in 24 hrs unless I have 3+ pts. Would you mind up voting the issue so that I can more easily respond...

RCRT Structure.PNG

Chris C3

Fidel, I accidentally responded to you within my own question, please see there.

Chris C3

Hi Doug. Thank you for the response! I have the same questions for you as I do for Fidel which I noted below. Thanks again for helping / thinking through this.

Fidel Castro

Can we consider that a Hiring Manager can't have more than one Hiring Request linked to a same Candidate? That assumption would simplify the workflow, and would make unnecessary the usage of subtasks.

Chris C3

A Hiring Manager in our context is like a 'lead project manager for a department' . So for infrastructure hiring manager, he might have 4 open positions for similar roles (connectivity engineer, network switch config, etc). So I think it should be possible for a candidate to fit multiple of the open positions under a single hiring manager.

If it makes it easier, I think it could work to say the hiring manager can only approve a candidate for a single one of his roles (and gets delinked from others?). Does this make sense?

Fidel Castro

A possible approach is this one:

If a Hiring Manager is rejecting a Candidate for the last of its pending Hiring Request, then the Candidate issue will be transitioned to Rejected status.

All this can be done using conditions, validations and post-functions of JIRA Workflow toolbox.

Chris C3

This sounds like a good solution. Just have one last question before I'm going to go ahead with the plugin and mark this is as the answer:

How does this work when the candidate is viable (and linked to) multiple hiring requests with different Hiring Managers (Requester field). This could be a fairly common scenario. For example, someone with a strong c++ background may be good for both the Optimization Hiring Manager's team under a request, and also the Machine Learning Hiring Manager's team. The candidate would be linked to both but can only be moved to rejected if both different hiring managers dont want him. Is that possible and not significantly different from your proposed solution?

Fidel Castro

I have already explained it, but not with enough detail. Now, I do:

Each time a Reject Candidate transition is triggered, the corresponding Hiring Request (actually its issue key) is added to Rejections custom field.

If all the Hiring Request the Candidate is linked to have been rejected (i.e., are present in Rejections field) then an auto-transition is executed automatically moving the Candidate to Rejected status. This transition will remain hidden while not all the Hiring Request are present in Rejections field, this way we prevent that a user mistakenly rejects the Candidate.

Anyway, I have told you, the Candidate will automatically transition to Rejected status when he is rejected for the last remaining Hiring Request (i.e., Reject Candidate reflexive transition is executed for the last Hiring Request), therefore, in practice, transition to Rejected status will never be executed manually by a user.

Doug Swartz

Fidel's hidden field approach will work. My approach uses the status in a subtask of the candidate for each hiring request for which the candidate is being considered.

I understand your wish to use structure to simplify nominating a candidate to be considered for a position.. Unfortunately, as you note, that does make using the subtask a bit of a challenge. The advantage of the subtask is that it's easy to look at the candidate issue and see all the jobs she's been considered for and the status of that consideration "at a glance".

One of your questions about using a subtask could be addressed by another feature of the workflow toolbox: the toolbox supports easily copying data from the parent issue into a subtask, Thus, if it were the subtask appearing in the Structure tree rather than the base candidate data, you wouldn't have to click twice to see basic candidate data.

The big challenge is creating the subtask using the simple drag and drop in the Structure.

Radu Dumitriu

No need for "reflexive transitions" => use Blitz Actions to lower the number of transitions.

JJUPIN + Blitz Actions is exactly what you need.

https://marketplace.atlassian.com/plugins/com.keplerrominfo.jira.plugins.blitz-actions/server/overview

https://marketplace.atlassian.com/plugins/com.keplerrominfo.jira.plugins.jjupin/server/overview

Fidel Castro

Chris,

You can ask for support about how implementing this use case using JIRA Workflow Toolbox. I will give you all the details you need.

Regards.

Ligia Merciu

Hi Chris,

As Radu mentioned above, the combination between JJUPIN + Blitz Actions

https://marketplace.atlassian.com/plugins/com.keplerrominfo.jira.plugins.blitz-actions/server/overview

https://marketplace.atlassian.com/plugins/com.keplerrominfo.jira.plugins.jjupin/server/overview

is the most appropriate to fulfill all the needs for your workflow: JJUPIN can manage custom conditions, validators and post-functions (and more) and Blitz Action helps to keep under control the number of transitions where you need to perform actions on an issue without changing its status. It looks like buttons on issue view screen smile

In addition, maybe an external decision table should be needed as well. It could be accessed by JJUPIN through SIL routines.

Hero Man

happy

Hero Man

😜

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration

jira-core

transition

workflow

issue-link

approver