Useful way to control rules triggering when a candidate comes from Recruitment & Onboarding

[NathanWilkinson]

If you are deploying Onboarding into an instance that is already live with Employee Central, then during the implementation will need to be mindful of the rules that have already been created.    If you have data created in recruitment and then mapped to Onboarding, then rules may disrupt the data by triggering again. 

For example, in Employee Central we have the following rule that opens recurring pay components and populates the data.  However, when data is sent from recruitment this data can be stripped out by the rule triggering again, especially for ‘oninit’ rules where you can’t control the context.

One alternative is to configure the solution below.

1. Create a picklist as follows.

2. Create a custom field on ‘employmentinfo’ as shown below and assign this to employee and onboardee person types.

3. In recruitment create a custom field with the picklist and using a rule set the value to RCM

4. Map this to the custom field to the field ‘employmentinfo’. 

5. Build the following rule and assign this ‘onchange’ to a field in job information.  This will set the value = ONB if you manually start onboarding.

6. Set the context as follows.

7. Create this rule.

8. Assign this rule on change of a field in job information with the following context.  This will set the value = EC when you manually add a hire in Employee Central.

This will now ensure the custom field in employment info is populated as follows:

• Sent from Recruitment = RCM
• Manually started in Onboarding = ONB
• Hired directly into Employee Central = EC

You can now use the custom field to trigger rules to behave differently based on how you start the process.

Our original rule now looks like this:

This field is very useful in allowing other rules to behave different especially for ‘oninit’ rules when the rules context is not supported.