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:

1. create a custom lookup type to store all possible values
2. create a table-validated value set that filters those values based on legislation
3. 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:

• +IN means the value is available only for India
• +GB means the value is available only for Great Britain
• +US,+CA,+IN means 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 TAG is null, the value is treated as global and shown to everyone
• if the TAG starts with +, the value is shown only if the employee’s legislation code exists in the tag
• if the TAG starts 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

1. open the Assignment EFF
2. create a new context
3. add a new segment
4. assign the value set XX_CUSTOM_ELIGIBILITY_VS
5. 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

How to Configure Context-Sensitive Descriptive Flexfields (DFF) for Absence Types in Oracle Fusion HCM

Introduction

Organizations frequently need to capture different information depending on the absence type selected by an employee.

Absence Type	Additional Information Required
Paid Time Off	Paid Time Off Attribute
Sick Leave	Sick Leave Attribute

Instead of customizing the application, Oracle Fusion Absence Management provides this capability through Context-Sensitive Descriptive Flexfields (DFF). This configuration allows the system to automatically display relevant fields depending on the selected absence type.

Solution Overview

This solution uses the Absence Recording Descriptive Flexfield (DFF) available in Oracle Fusion Absence Management.

1. Access the Absence Recording DFF
2. Configure the Context
3. Create contexts and context sensitive segments
4. Deploy the flexfield

(1) Access the Absence Recording DFF

Navigate to:

Setup and Maintenance → Manage Descriptive Flexfields

Search for Absence Recording DFF and click the Edit icon.

Step 2 – Configure the Context

Parameter	Value
Default Type	Parameter
Default Value	Absence Type
Derivation Value	Absence Type
Display Type	Hidden

This ensures the context is automatically derived from the absence type.

Step 3 – Define Context and Context Sensitive Segments

Create Contexts for Each Absence Type

Next, click the Manage Contexts button to view existing contexts or create new ones.

On the Manage Contexts page, click the “+” (Add) icon to create a new context.

When creating a context:

• You can enter any value for the Display Name

• The Context Code must be the absence_type_id

The system uses this value to determine which set of fields should be displayed for the selected absence type.

Retrieve the Absence Type ID

To obtain the absence_type_id, run the following SQL query:

SELECT *
FROM ANC_ABSENCE_TYPES_F_TL
WHERE language = 'US'
AND name IN ('Paid Time Off','Sick Leave');

This query retrieves the IDs for the required absence types. Use the corresponding absence_type_id as the Context Code when creating the context.

Once the context is created, you can define context-specific segments that should appear when that absence type is selected.

Paid Time Off

• Paid Time Off Attribute

Let's define another context and related segments

Sick Leave

• Sick Leave Attribute

Step 4 – Deploy the Flexfield

Save the configuration and click Deploy Flexfield. Ensure deployment status shows successful compilation.

Testing the Configuration

Navigate to:

My Client Groups → Absence → Absences and Entitlements

Create a new absence request and verify the fields appear dynamically based on absence type.

Best Practices

• Use Global Segments only for fields applicable to all absence types
• Ensure context code matches absence_type_id
• Keep Context Segment hidden
• Always deploy flexfields after configuration

Conclusion

Using Context-Sensitive Descriptive Flexfields in Oracle Fusion Absence Management, organizations can dynamically capture absence-specific information without customization. This improves data accuracy, user experience, and system flexibility.