Configuring Public Workers for Oracle Search

A single, enterprise-wide configuration user interface developed using Redwood patterns, called Configure Public Workers Access, can now be used to determine which public workers are returned when using Oracle Search. For example, when using Connections, a user is initially prompted for the person’s name whose information they are looking for. By configuring Public Worker Access, you are now able to create a filter that lets you to hide sensitive or non-public workers by user-defined criteria, such as job code, position, business units, and other criteria. This filter is also applied to the global search and public worker LOVs that use Oracle Search, including non-HCM products, such as Procurement, Supply Chain Management, etc.

To define Public Worker Access filtering, an IT Security Manager user can navigate from My Client Groups to the quick action found in either of these paths:

Apps > Workforce Structures > Public Worker Access Configurations > Public Worker Access
My Client Groups > Show more > Workforce Structures > Public Worker Access

Once you opt-in to this feature enhancement, your IT Security Managers can define certain criteria to restrict the visible workers seen in the Oracle Search public worker LOVs.

This information will be presented based on the supported, primary use case scenarios, namely:

View all workers in the enterprise, but exclude certain people based on criteria;
View workers from the user’s own legal employer;
View workers from the user’s own business unit; and
View workers based on other inclusion criteria.

As you’ll see, Status is a read-only field. This value is determined based on the Enable Public Worker Access Using Security Filters Enabled profile option. It is Active when the profile option is enabled, and Inactive when this profile option is disabled. If the profile option is disabled, no filtering will occur, and you'll see all workers, which is the current behavior.

In all cases described below, you'll get an error if you attempt to add multiple rows of the same criteria within an exclusion set. Likewise, an error appears when you have the same criteria defined in inclusion and exclusion criteria sets, as described in scenario #4.

Scenario 1: View All Workers in the Enterprise, but Exclude Certain People based on Criteria

If you want to include All workers with certain groups to exclude, you can do this by choosing one or more values from the available criteria which includes the following:

Assignment status
Business unit
Department
Grade
Job
Legal employer
Person
Person Type (both user and system person types).

Public Worker Access Page Where the All Workers Option Is Chosen, along with Person Type Exclusion Criteria

Example 1: Public Worker Access Page Where the All Workers Option Is Chosen, along with Person Type Exclusion Criteria

With the All workers option, you can configure multiple criteria and values to exclude. Based on the example above, the public workers LOV will list all workers in your organization that are not consultants, seasonal workers, or retirees.

Scenario 2: View Workers from the User’s Own Legal Employer, but Exclude Certain People based on Criteria

If you want to include Workers in a user’s legal employer, this option uses the legal employer from the signed-in user’s assignment(s). If the worker has multiple assignments in different legal employers, then workers from those legal employers will be evaluated. With this option, you can further limit access from those legal employers by choosing one or more values from the available exclusion criteria which includes the following:

Assignment status
Business unit
Department
Grade
Job
Person
Person Type (both user and system person types).

Public Worker Access Page Where the Workers in User’s Legal Employer Option Is Chosen, Along with Multiple Exclusion Criteria

Example 2: Public Worker Access Page Where the Workers in User’s Legal Employer Option Is Chosen, along with Multiple Exclusion Criteria

With the Workers in a user’s legal employer option, you can configure multiple criteria and values to exclude, except for legal employer. An error appears if you choose a legal employer as this choice conflicts with the public workers inclusion selection.

Based on the example above, the public workers LOV will list all workers in the signed-in user’s legal employer that are not in Human Resources or Payroll Departments, aren't suspended, and aren’t consultants, seasonal workers, or retirees.

Scenario 3: View Workers from the User’s Own Business Unit, but Exclude Certain People based on Criteria

If you want to include Workers in a user’s business unit, this option uses the business unit from the signed-in user’s assignment(s). If the worker has multiple assignments in different business units, then workers from those business units will be evaluated. With this option, you can further limit access from workers in those business units by choosing one or more values from the available exclusion criteria which includes the following:

Assignment status
Business unit
Department
Grade
Job
Legal employer
Person
Person Type (both user and system person types).

Public Worker Access Page Where the Workers in User’s Business Unit Option Is Chosen, Along with Multiple Exclusion Criteria

Example 3: Public Worker Access Page Where the Workers in User’s Business Unit Option Is Chosen, along with Multiple Exclusion Criteria

With the Workers in a user’s business unit option, you can configure multiple criteria and values to exclude, except for business unit. An error appears if you choose Business unit as this choice conflicts with the public workers inclusion selection.

Based on the example above, the public workers LOV will list all workers in the signed-in user’s business units that aren't in a grade of EXTS_GRADE, aren't in CEO or CFO jobs, and aren’t consultants or pending workers. Additionally, Larry Benson is identified as a sensitive person, so he will also be filtered out.

Scenario 4: View Workers Based on Other Inclusion Criteria

Lastly, if the earlier options don’t suit your needs, you want to define another set of workers to include. For this, we let you choose the Other inclusion criteria option. Here you have the choice to choose one or more values from the available inclusion criteria which includes the following:

Assignment status
Business unit
Legal employer
Person type

If the worker has multiple assignments in different business units, then workers from those business units will be evaluated. With this option, you can further limit access from workers in those business units by choosing one or more values from the available exclusion criteria which includes the following:

Assignment status
Business unit
Department
Grade
Job
Legal employer
Person
Person Type (both user and system person types).

Note that you can’t define exclusion criteria for any of these same inclusion criteria. If you want to exclude a value, then simply remove it from the inclusion criterion values. Inversely, it may be advantageous to define a shorter list of exclusion criterion values instead. It depends on the number of corresponding values defined by your organization. You’ll have to assess which is easier to manage during your implementation.

Public Worker Access Page Where the Other Inclusion Criteria Option Is Chosen, Along with Multiple Inclusion and Exclusion Criteria

Example 4: Public Worker Access Page Where the Other Inclusion Criteria Option Is Chosen, along with Multiple Inclusion and Exclusion Criteria

With the Other inclusion criteria option, you can configure multiple criteria and values to include and exclude. Based on the example above, the public workers LOV will list all workers in the 4 specified Vision legal employers that are people with an active assignment status. Further excluded from the public worker search, is anyone in the Vision BR Payments BU business unit, including the 4 people provided in the Person List of Values (LOV).

Guided Journey

If you choose to add a guided journey to Public Worker Access, this option is available to you with this release.

You can now restrict public workers for Oracle Search using Redwood Configure Public Worker Access. For example, you can hide certain groups of workers, such as external consultants, from the Connections person search.

Steps to Enable

Enable the following profile option:

ORA_PER_PUBLIC_WORKER_ACCESS_ENABLED (Enable Public Worker Access Using Security Filters Enabled)

For details, see How do I enable a profile option?

For more details on enabling Redwood for HCM, see How do I adopt Redwood for HCM?.

Tips And Considerations

If your organization’s business requirements allow users to search across all workers, then there’s no need to enable public worker access!

Use of Oracle Search is a pre-requisite for Redwood user interfaces.

This is an enterprise-wide configuration, so access can't vary based on a user’s assigned data role.
Auditing and migration to other environments using Setup Manager (FSM) is not yet available.

This feature does not replace the use of the existing security profiles or HCM data roles.
You will see a functional behavior change after implementing this feature on the Connections’ initial person search; however, searching for a person within the Connections organization hierarchy is controlled by the public person security profile. Therefore, you must keep these inline and maintain both configurations so you don’t get inconsistent results, i.e., exposing excluded people as they come and go through your organization.

Key Resources

Oracle Search-Based Global Search feature in the 22B HCM Common What's New.
Oracle Search Cloud Service Setup > Set Up Oracle Search for HCM in the Using Common Features for HCM guide. Pay attention to fa-hcm-person index, in particular.
Overview of Guided Journeys

Access Requirements

To use this feature, you need this job role name and code:

IT Security Manager (ORA_FND_IT_SECURITY_MANAGER_JOB)

No role changes are necessary to access this feature.

However, in case you have certain users, such as a Corporate HR Manager, that must have “view all” access to all public workers and needs to bypass the enterprise-wide Public Worker Access Configuration, you can assign this orphaned, aggregate privilege to a role assigned to your user:

Privilege Name and Code

Privilege Name	Privilege Code
View All Public Workers	ORA_PER_VIEW_ALL_PUBLIC_WORKERS

Note that View All Public Workers aggregate privilege only applies to public workers that are retrieved by Oracle Search. This privilege does impact the behavior of the public person security profile and will not impact the results returned by BI reports, for example.