How to Build Dependent Parameters for an ESS Job in Oracle Fusion Cloud

If we've ever built a scheduled process in Oracle Fusion Cloud with more than one parameter, we've probably run into this problem: parameter B should only show values that make sense for whatever was picked in parameter A.

For example: a "Load Type" of DELTA might be valid for one workspace but meaningless for another. Hard-coding a single flat list for both parameters either lets users pick invalid combinations, or forces us to build one giant, confusing dropdown.

The fix is a dependent (cascading) parameter, driven by a dependent value set and a bind variable mapping on the job definition's List of Values (LOV) source. This walkthrough covers the full setup, end to end, using a real ESS (Enterprise Scheduler Service) job as the example.

In our example we will be doing this through a value set, but we can create dependent parameters for ESS jobs using any existing PVOs that support it, like Lookups, using a similar approach.

What We're Building

Two parameters on a scheduled process:

• Workspace — an independent dropdown (e.g. Backlog CPM, Backlog FPA, etc.)
• Load Type — a dependent dropdown whose options change based on which Workspace is selected. For example, the CPM workspace only offers FULL, while FPA offers FULL, DELTA, and REPLACE.

Getting there takes four stages: create the value sets, wire them to the LOV source, attach them to the job's parameters, and configure the dependency between the two parameters.

Create the Independent Value Set

We start in Setup and Maintenance, and search for the Manage Value Sets task.

We open the task and use the search panel to confirm no existing value set covers what we need, then click the + icon in the Search Results toolbar to create a new one.

We create the first value set this one holds the Workspace options. We give it a code, an API name, set the Module to Application Common, Validation Type to Independent, and Value Data Type to Character.

We save it, then review the full definition page to confirm the module, validation type, and max length are correct.

 

Populate the Workspace Values

From the value set, we open Manage Values and add each Workspace option with a short code and a description.

For this example, we added four workspace values:

Value	Description
CPM	Backlog CPM
DB_EXITR	Exit Rate DB
FPA	Backlog FPA
FPA_EXITR	Exit Rate FPA

Create One Dependent Value Set per Workspace Value

This is the part that trips people up: a dependent value set in Oracle Fusion isn't one value set with conditional logic inside it — it's a separate value set per parent value, named to match. Since we have four Workspace values, we need up to four Load Type value sets, one named CPM, one named FPA, and so on. We only need to build the ones that actually need different Load Type options; here we'll walk through CPM and FPA.

We create a value set named CPM:

We add its values -in this case, just FULL:

We create a second value set named FPA:

This one gets three values — FULL, DELTA, and REPLACE — since the FPA workspace supports more load strategies:

The naming convention (value set name == parent value) is what lets Oracle's dependent-value-set validation type resolve the right list at runtime once the bind variable is wired up in the dependency step below.

Point the Job's LOV Source at the Value Set API

Next, we head to Manage Enterprise Scheduler Job Definitions and Job Sets, open the Manage List of Values Sources tab, and search for the standard ValueSetValuePVO source under the Application Toolkit application.

We open it to confirm the source definition - this is the shared view object Oracle provides specifically for exposing value set values as a job parameter LOV.

 

Attach the Parameters to the Job Definition

We open the job definition itself (in this example, an ESS job that loads data for a given workspace).

On the Parameters tab, we edit the Workspace parameter: set its Page Element to Choice list, its List of Values Source to ValueSetValuePVO, and its Attribute to Value. Under Derived Attributes, we map the view attribute Workspace to the list attribute Value, and move Description into Selected Attributes so the dropdown shows friendly labels.

 

We do the same for the Load Type parameter — same LOV source, same general configuration, but this one is the parameter we'll filter dynamically.

This is the step that actually makes the cascading behavior work. Back on the Parameters tab, we use 

the dependency icon to open Manage List of Values Dependencies.

For the Workspace parameter's LOV, we move ValueSetIdCriteria into Selected View Criteria, then set its bind variable's Default Value to the code of the Workspace value set itself (the one we created in the first step). This tells the LOV which value set to pull the top-level Workspace options from.

For the Load Type parameter's LOV, we do the same, but this time set the bind variable's Mapped Parameter to Workspace instead of a static default. This is the actual cascade: at runtime, Oracle takes whatever we picked for Workspace, uses it as the value set code, and looks up the matching dependent value set (CPM, FPA, etc.) for the Load Type options.

Save and close after making the changes:

Testing It

We submit the scheduled process and confirm the cascade works as expected.

With no Workspace selected, Load Type has nothing to show yet:

We select Backlog CPM as the Workspace, and Load Type narrows to just FULL:

We select Backlog FPA instead, and Load Type now offers FULL, DELTA, and REPLACE:

Here we submit it with FULL chosen for the FPA workspace:

Once submitted, the process's parameter values confirm exactly what we passed through — the integration ID and the selected load type:

In our example we created this using a value set, but we can create dependent parameters for ESS jobs using any existing PVOs — like for Lookups, etc. — using a similar approach.