How to Restrict Global Assignment EFF Values by Employee Legislation in Oracle Fusion HCM
In global Oracle Fusion HCM implementations, one of the more common configuration challenges is supporting local business requirements without fragmenting the overall design. A field may be global in nature, but the values available for that field often need to vary by country or legislation.
A typical example is a custom field on the Global Assignment Extensible Flexfield (EFF). The business may want one common field for all employees, but the list of available values should differ depending on whether the worker belongs to the US, India, Canada, Great Britain, or another legislation.
The good news is that Oracle Fusion HCM supports this requirement quite elegantly through configuration. By combining a custom lookup, a table-validated value set, and a Global Assignment EFF segment, you can create a clean, scalable, and metadata-driven solution.
In this article, I’ll walk through a practical design pattern for restricting Assignment EFF values based on employee legislation.
Business Requirement
Let’s assume the business wants to add a custom Assignment EFF field called Eligibility Type. This field should behave differently depending on the employee’s legislation.
For example:
- an employee with India legislation should see values relevant to India
- an employee with Great Britain legislation should see UK-specific values
- an employee with US legislation should see US-specific values
- some values should remain available to all employees regardless of country
This is a common global design problem: one field, different valid values by legislation.
Instead of creating separate fields or separate contexts by country, we can keep the design centralized and let the value filtering happen dynamically at runtime.
Solution Overview
The solution has three building blocks:
- create a custom lookup type to store all possible values
- create a table-validated value set that filters those values based on legislation
- assign that value set to a Global Assignment EFF segment
The key idea is straightforward: all possible values are maintained in a single lookup, and the Tag field is used to identify country applicability. The value set then reads those values and decides which ones should be displayed based on the employee’s legislation code.
This approach keeps the design simple, maintainable, and easy to extend later.
Step 1: Create a Custom Lookup Type
The first step is to create a custom lookup that will act as the source for the field values.
Navigation
Setup and Maintenance → Manage Common Lookups
Create the following lookup type:
| Field | Value |
|---|---|
| Lookup Type | XX_CUSTOM_ELIGIBILITY |
| Meaning | XX_CUSTOM_ELIGIBILITY |
| Description | XX_CUSTOM_ELIGIBILITY |
| Module | Global Human Resources |
Once the lookup type is created, add the lookup codes that will represent the values shown in the EFF.
Sample Lookup Codes
| Lookup Code | Meaning | Start Date | Tag |
|---|---|---|---|
GRND_FATHER |
Grandfathered in | 1/1/1951 | +IN |
HAZARD_ALLOWANCE |
Hazard Allowance | 1/1/1951 | +GB |
ONCALL |
On Call | 1/1/1951 | +US,+CA,+IN |
STIPEND_INCENTIVE |
Stipend Incentive | 1/1/1951 | (blank) |
Using the Tag Column to Drive Legislation Logic
The Tag column is central to this pattern.
In this configuration:
+INmeans the value is available only for India+GBmeans the value is available only for Great Britain+US,+CA,+INmeans the value is available for multiple legislations- a blank tag means the value is available globally
This gives you a very practical mechanism for managing legislation-specific behavior without overcomplicating the EFF structure itself.
It also makes future maintenance easier. If the business wants to add a new value or expand eligibility to another legislation, the update can often be handled directly in the lookup.
Step 2: Create a Table-Validated Value Set
The next step is to create a value set that reads the lookup values and filters them using the legislation code of the employee.
Navigation
Setup and Maintenance → Manage Value Sets
Create the value set with the following definition:
| Field | Value |
|---|---|
| Value Set Code | XX_CUSTOM_ELIGIBILITY_VS |
| Description | XX_CUSTOM_ELIGIBILITY_VS |
| Module | Global Human Resources |
| Validation Type | Table |
| Value Data Type | Character |
Table Validation Details
| Field | Value |
|---|---|
| From Clause | fnd_lookup_values |
| Value Column Name | meaning |
| Description Column Name | meaning |
| ID Column Name | meaning |
Where Clause
LOOKUP_TYPE = 'XX_CUSTOM_ELIGIBILITY'
AND (
DECODE(
TAG,
NULL, 'Y',
DECODE(
SUBSTR(TAG,1,1),
'+', DECODE(SIGN(INSTR(TAG, :{PARAMETER.LEGISLATION_CODE_VALUE})), 1, 'Y', 'N'),
'-', DECODE(SIGN(INSTR(TAG, :{PARAMETER.LEGISLATION_CODE_VALUE})), 1, 'N', 'Y'),
'Y'
)
) = 'Y'
)
AND LANGUAGE = 'US'This is the heart of the solution.
How the Value Set Logic Works
At runtime, the value set checks the TAG value for each lookup row.
The logic works like this:
- if the
TAGis null, the value is treated as global and shown to everyone - if the
TAGstarts with+, the value is shown only if the employee’s legislation code exists in the tag - if the
TAGstarts with-, the value is hidden if the employee’s legislation code exists in the tag
This creates a flexible filtering mechanism while keeping the actual list of values centrally managed.
From a design perspective, this is a strong pattern because it separates value maintenance in the lookup, filtering logic in the value set, and user entry in the EFF.
Step 3: Create the Global Assignment EFF Context and Segment
Once the lookup and value set are ready, the next step is to create the Global Assignment EFF segment that uses this value set.
Navigation
Setup and Maintenance → Manage Extensible Flexfields
Search for the Assignment Extensible Flexfield and create a new context and segment.
High-Level Steps
- open the Assignment EFF
- create a new context
- add a new segment
- assign the value set
XX_CUSTOM_ELIGIBILITY_VS - save and deploy the flexfield
The segment should be a character-based field configured to display as a list of values.
Important Detail: Legislation Code Parameter
The most important part of this configuration is the parameter referenced in the value set:
:{PARAMETER.LEGISLATION_CODE_VALUE}This parameter must receive the employee’s legislation code at runtime. That is what enables the value set to determine which rows should be displayed.
If this parameter is not mapped correctly, the LOV may not behave as expected. In most cases, the issue will show up as one of the following:
- all values are displayed
- no values are displayed
- values appear inconsistently for different employees
Because of that, parameter mapping is usually the first thing to verify during testing.
Testing the Configuration
Once the EFF is deployed, test the setup with employees from different legislations.
Based on the sample configuration above, the expected results are:
| Employee Legislation | Values Displayed |
|---|---|
| US | On Call, Stipend Incentive |
| IN | Grandfathered in, On Call, Stipend Incentive |
| CA | On Call, Stipend Incentive |
| GB | Hazard Allowance, Stipend Incentive |
This confirms that the same field can support different value sets depending on employee context, without requiring country-specific duplication in the flexfield design.
US Employee
India Employee
Canada Employee
GB Employee - redwood UI
Why This Design Works Well
What makes this approach especially useful in global implementations is its balance between flexibility and simplicity.
Rather than designing multiple country-specific fields or managing complex configurations in several places, you keep the setup centralized:
- the lookup stores all available values
- the Tag defines country applicability
- the value set handles runtime filtering
- the EFF consumes the filtered result
This makes the solution easier to maintain, easier to explain, and easier to extend over time.
It also aligns well with a broader Oracle HCM design principle: whenever possible, solve requirements through configurable metadata rather than proliferating structures.
Final Thoughts
For global Oracle Fusion HCM implementations, legislation-sensitive value restriction is a requirement that comes up often. The combination of a custom lookup, country-tagged values, a table-validated value set, and a Global Assignment EFF provides a neat and reusable way to address it.
It keeps the configuration centralized, supports local variation, and avoids unnecessary duplication in your flexfield design.
If you are working on a global HCM rollout and need different LOV values for the same field across legislations, this is a pattern well worth keeping in your implementation toolkit.
Key Takeaways
- a single Assignment EFF field can support different values by legislation
- the lookup Tag column is a simple way to define country applicability
- a table-validated value set can dynamically filter values at runtime
- this pattern is scalable, maintainable, and well suited for global HCM implementations
.png)
