Brook Preloader

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

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

And/Or Field Operator Comparison Type Comparison Value
And Business Process Type in the selection list Value specified in this filter Role Assignment Event
And Role Proposed in the selection list Value specified in this filter Primary Recruiter
And Role Assigned To is not empty

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

And/Or Field Operator Comparison Type Comparison Value
And Business Process Type in the selection list Value specified in this filter Role Assignment Event
And Role Proposed in the selection list Value specified in this filter Primary Recruiter
And Role Assigned To is empty

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

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

And/Or ( Field Operator Comparison Type Comparison Value )
And ( CF #1: EMI Role Assignment Event Subprocess for Primary Recruiter Role with Assignee is empty  
And Business Process Name In the selection list Value specified in this filter Job Requisition

Evergreen Requisition

)
Or ( CF #3: EMI Role Assignment Event Subprocess for Primary Recruiter Role without Assignee is not empty )
Or ( CF #1: EMI Role Assignment Event Subprocess for Primary Recruiter Role with Assignee is not empty  
And   CF #3: EMI Role Assignment Event Subprocess for Primary Recruiter Role without Assignee is not empty )

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

One at a time, access the Job Requisition, Evergreen Requisition, Evergreen Requisition Change, and Job Requisition Change business processes and perform these actions to add a new condition rule to the Initiation step of each:

  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 Assignment Error” and in the grid, enter the following:
And/Or Field Operator Comparison Type Comparison Value
And TF Role Assignment Error Equal to Value specified in this filter Yes (check the box)


Click OK to save the condition and return to the business 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!

Author

  • Nate Borsella

    Nate Borsella has been with the Workday Ecosystem since 2015 as a day-to-day Manager and HRIS Analyst for everything from a university to a global corporation. Nate has successfully stabilized several implementations servicing most functional areas in Workday. This includes recruiting, benefits, talent and performance, configurable security, advanced compensation, and his personal favorite, reporting. Nate currently works as a consultant from his home office in rural Idaho.