Make Primary Recruiter Assignments Required: A Workday Recruiting How-To

Do you ever open your Workday inbox and see yet another unassigned task for Post Job because the associated Job Requisition has no Primary Recruiter assigned? Do you ask yourself why it’s so difficult to find an appropriate solution for validating that a Primary Recruiter is present? Do you also want to ensure that Primary Recruiters aren’t removed incorrectly if a Job Req is edited? Well, I have the solution!

I, too, have experienced many misgivings that there isn’t already a delivered process for this requirement, but after hours of running into the same issues repeatedly, a solution finally materialized. The think-tank we have here at Kognitiv is a potent resource for us internal consultants and really can turn out some amazing things. I could not have done this alone and I am grateful to our Security and Recruiting Product Leads for helping me figure it out. Now, on with the show!

Building the pieces

The solution requires that you configure a few calculated fields placed in a condition rule on a consolidated template. Read through to make sure you understand, then build them out in your own Sandbox or Implementation tenant to test!

1. Create Calculated Field #1:

Field Name: EMI Role Assignment Event Subprocess for Primary Recruiter Role with Assignee
Business Object: Action Event
Type: Extract Multi-Instance

Operation Type: Subset
Source Field: Business Processes part of this Business Process
Related Business Object: Action Event
Condition: select “Create Calculated Field” and proceed to the next step

2. Create Calculated Field #2 (within #1):

Field Name: TF Event is Role Assignment Event for Primary Recruiter role with assignee
Business Object: Action Event
Type: True/False Condition

3. Create Calculated Field #3:

Field Name: EMI Role Assignment Event Subprocess for Primary Recruiter Role without Assignee
Business Object: Action Event
Type: Extract Multi-Instance

Operation Type: Subset
Source Field: Business Processes part of this Business Process
Related Business Object: Action Event
Condition: select “Create Calculated Field” and proceed to the next step

4. Create Calculated Field #4 (within #3):

Field Name: TF Event is Role Assignment Event for Primary Recruiter role without assignee
Business Object: Action Event
Type: True/False Condition

5. Create Calculated Field #5 (where the rubber meets the road!):

Field: TF Role Assignment Error
Business Object: Action Event
Type: True/False Condition

How this calculation works:

• The first grouping captures any issues with missed role assignments during a job requisition creation event
• The second grouping applies if role assignments were removed during a job requisition change
• The third grouping comes into effect if no change was made during a correction. No action event was created AND because of that, there will be no action events without assignees.

Putting it all together

Access any one of the four applicable business processes (Job Requisition, Evergreen Requisition, Evergreen Requisition Change, or Job Requisition Change) and create a new Condition Rule from the initiation step. 

1. From the initiation step’s related actions, select Business Process > Maintain Step Conditions; click OK.
2. Add a row to the Validation Conditions. The line will default to “critical”, meaning they will not be able to move forward until the validation clears. (Making this rule critical will ensure Primary Recruiter can no longer be excluded from Job Requisitions!)
3. Select “Create Condition Rule” within the new row’s list; click OK. Give your new rule a meaningful name such as “Primary Recruiter Required” and in the grid, enter the following:

4. Access each of the other three processes and add the same condition created in steps 1-3 as a Critical Validation Condition. The original rule will be available to use across each process.

For bonus points: from your new condition in the Validation column, select the related actions > Validation > Configure Validation Message. Add text and/or fields to customize the error message received if a Primary Recruiter is left blank in the process.

Now what?

Now that you can ensure Job Requisition events, regardless of creation or edit action, will require the user to assign a Primary Recruiter, you shouldn’t have any more of those pesky unassigned Post Job tasks (or otherwise) fettering your inbox. Also, any downstream duties to be performed by the Primary Recruiter will not be inadvertently missed. This will save you administrative time and effort and create greater overall trust within the system from your recruiting team, resulting in better and easier adoption.

If you found this helpful or have any questions you’d like to reach out about, please contact us today. Who knows, perhaps you will get to work with me or one of my amazing colleagues here at Kognitiv!