Optimizing Dynamic Group Creation and New Hire Data Review
My client had a large number of offices and training locations—around 250+—each responsible for reviewing new hire data for incoming employees. This created a need for multiple Dynamic Groups and a complex set of rules to select the correct locations based on predefined criteria.
To simplify this, we implemented a structured solution, which I will explain step by step below.
Step 1: Configuring the Training Location Field in Recruiting
At the application stage, where the correct location for the employee is selected during the recruiting process, we created a Training Location field with the same picklist values as in Employee Central (EC).
This field carries the value over to EC, which becomes the **key deciding factor** for determining which group will be selected for reviewing new hire data.
Note: This blog does not cover how to create a field in the RCM application or how to map that field to ONB.
Step 2: Creating and Configuring the Object
Once the field was set up, we created an object as shown below.
Please ensure that the following fields are configured as indicated:
Object: cust_ONB2ResponsibilityDetailConfig
* The second field must match the value from Recruiting. It should have the same data type and field configuration as in Recruiting to enable proper mapping and data transfer to Onboarding.
Step 3: Setting Permissions
It’s essential to assign the correct permissions to the object before entering data.
Once the permissions are set, the object should appear as shown below:
---
Step 4: Creating the Business Rule
Next, we designed a **business rule** to control the group selection logic. This rule determines which dynamic group should be picked based on the training location value passed from Recruiting.
---
Data Collection Object Configuration
The second part of the requirement involved handling **various data collection UIs**, which the customer wanted to display based on specific conditions.
To achieve this, we created a **new object definition** as illustrated below:
We added the **foundation object: Location Group**, since each combination of **Location Group + Company + Employee Group** determines the type of object to be displayed.
Additionally, the **Object UI** must include the following configuration:
Once the object is uploaded, it should look like this:
Finally, we designed a Rule to pick the appropriate lookup table configuration**. The rule should resemble the structure shown below:
Conclusion
By standardizing the location field, creating a well-structured object, and designing targeted business rules, we were able to eliminate the need for lengthy line items in dynamic group creation. This approach not only improves system performance but also provides flexibility in data collection UI configuration based on location and organizational attributes.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| User | Count |
|---|---|
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |