Extract Multi-Instance: It’s More Than Just a Subset

Extract Multi-Instance is a useful Workday calculated field when working with one-to-many relationships between business objects. If you think Extract Multi-Instance (EMI) is only used to return a subset of a multi-instance field, you are underutilizing its full potential. EMI has 4 functions: union, except, intersection, and subset. Let’s get into each one!

Subset Function

This function allows you to take a subset of a multi-instance field using a calculated field condition. The calculated field condition must be on the related business object of the multi-instance field you are extracting from. This is a good function to reduce the number of instances returned if you do not need to see every instance or only want to see instances that meet a specific condition.

For example, there is a multi-instance field called Staffing History – Approved on the worker object. It shows all approved staffing events on the worker record. If I only wanted to return all the approved staffing events where the location changed, I would use the subset function on an EMI. Creating a True False (T/F) condition identifying events with a location change on the staffing event object, I can create an EMI to only return staffing events for which there is also a location change.

Setup:

• Calculated Field Business Object: Worker
• Type: Extract Multi-Instance – Subset
• Source Field 1: Staffing History: Approved
• Condition: CF TF Location Changed (i.e. Location Current is not equal to Location Proposed)

Result: a new field that lists only staffing events that also have a change in location.

Except Function

This function allows you to compare two instance fields that share the same related business object. It will take the instances in Source Field 1 and remove any instances that are in Source Field 2. This is telling you what is “missing” in Source Field 2 when compared to Source Field 1. Think of a Venn diagram where Source Field 1 is the left side and Source Field 2 is the right side. The returned instances are those that are only on the left side of the Venn diagram with no overlap with the right side.

This function can be useful when troubleshooting security on reports. For example, you can compare a worker’s security groups to the required security groups for a data source or a report field. The below example shows the security groups needed for the custom report, the security groups the worker has, and the security groups that are “missing” from the worker to be able to search and run the custom report. The shared or related business object between Source Field 1 and Source Field 2 is security group, which allows us to compare the two Source Fields.

Setup:

• Calculated Field Business Object: Custom Report
• Type: Extract Multi-Instance – Except
• Source Field 1: EVAL Data Source Security Groups Needed (a custom calc field that presents the groups you need for the report)
• Condition: Is True
• Source Field 2: LRV Prompted Worker Security (a calc field that allows you to prompt for the worker and will produce their security groups)
• Condition: Is True

Result: a list of security groups that are missing from the worker but are required for accessing the custom report.

Intersection Function

This function allows you to see the common instances between Source Field 1 and Source Field 2. Both source fields need to share the same related business object. Think of this as the center of a Venn diagram between the two fields being compared.

An example of this function would be determining the common skills between a worker and the job profile they are assigned. It may require creating a few lookup related value calculated fields to get the correct business object on your primary object, but it can provide better report visibility and insights.

Setup:

• Calculated Field Business Object: Worker
• Type: Extract Multi-Instance – Intersection
• Source Field 1: Skills
• Condition: Is True
• Source Field 2: LRV Job Profile Skills (a calc field that pulls the required skills from the worker’s job profile)
• Condition: Is True

Result: a list of common skills from the worker and their assigned job profile.

Union Function

This final extract-multi instance function allows you to combine two multi-instance fields that share the same related business object. Think of this as stacking the two fields on top of one another.

An example of where this is practical is with calibration events on the worker object. There are two delivered fields between Worker and Worker Calibration Events business object. One field contains the in-progress calibration event and the other contains the completed calibration events. What if you wanted to write a calc field that pulls the most recent calibration event whether it is completed or in progress?

The best approach to solve this dilemma is to create an extract multi-instance calc field to union the two fields together to create a new field that returns all calibration events for the worker. Once this field is created, you can then use the new calc field in reporting and proceeding calc fields.

Setup:

• Calculated Field Business Object: Worker
• Type: Extract Multi-Instance – Union
• Source Field 1: Worker Calibration Event In Progress
• Condition: Is True
• Source Field 2: Worker Calibration Events
• Condition: Is True

Result: all calibration events for the worker.

Food for Thought on Conditions

When building out any Extract Multi-Instance calculation and using calculated fields, think about how you plan to use the field in practice. The calculated field can be rigid with hardcoded values (specify value), it can be dynamic using values from other fields, and you can embed promptable fields that would surface on a report definition, giving more flexibility.

Referring back to the subset example of only returning location changes, you could take it a step further by adding date prompts that would allow a user running the report to refine the time period they are interested in reviewing. Conversely, you can opt to not prompt the user, and use global fields to only return the year-to-date location changes.

A final example would be creating a Prompt for Value calculated field that allows you to prompt for the calibration program. This could then be used as a calculated field condition in the newly created union all calibration events field from the above example. This would save a lot of year-over-year maintenance on existing calculated fields by being able to prompt the calibration event program when running the custom report.

Hopefully this post will clarify any confusion you’ve had with using extra mult-instance calculated fields in the past, and will inspire you to get creating and using them! For more support, get in touch with Kognitiv today.