Sharing or Separating? A Simple Guide to Reference Data Sets

In our last article, we built our organizational blueprint. We defined our Enterprise, our Legal Entities, and most importantly, our Business Units (BUs) and Departments.

But this creates a new challenge. Imagine your company has two BUs: one in India and one in the United Kingdom. Should the HR team in the UK see the list of Departments that only exist in India? When they hire someone, should they have to scroll past all the Indian job titles and pay grades?

The answer is no. That would be confusing, inefficient, and lead to data entry errors.

We need a way to share some data (like a list of all countries) but separate other data (like department lists). The tool that gives us this powerful control is called Reference Data Sets, often just called "SetIDs".

What is a Reference Data Set?

A Reference Data Set (RDS) is simply a container, or a "list," that holds setup data. Think of it as a specific menu. Your lists of Departments, Jobs, Locations, and Grades are all held within these "sets."

The key is this: You then "subscribe" a Business Unit to a specific set for each data type. This is how you control what data a user in that BU can see and use.

The "COMMON" Set vs. Custom Sets

This is the most important part to understand. When you set up your system, you have two main choices.

1. The "COMMON" Set Oracle provides a default, global set called COMMON. Any piece of data (like a Job titled "Global CEO") that you put in the "COMMON" set can be seen and used by all Business Units. This is perfect for data that is truly shared everywhere.

2. Custom Sets This is where you take control. For our example, you would create two new, empty sets: one called IND_SET and one called UK_SET.

• You would put all your Indian Departments and Jobs into the IND_SET.
• You would put all your UK Departments and Jobs into the UK_SET.

Then, you connect everything. You tell the system:

1. The "India Business Unit" must use the IND_SET for its list of departments and jobs.
2. The "UK Business Unit" must use the UK_SET for its list of departments and jobs.

The result is pure, simple control. When a user in the India BU tries to hire someone, the dropdown menu for "Department" will only show them the list from the IND_SET. The UK departments are completely invisible to them.

See the Wires for Yourself

You can see this setup in the system without changing a thing.

Go to the Setup and Maintenance work area. First, search for the task Manage Reference Data Sets. You will see a list. You don't need to create anything, just find the one named COMMON to see the master set.

Next, search for the task Manage Business Unit Set Assignment. This is the most important screen for this concept. Here, you will see a list of your Business Units. You can see exactly which "Set" is assigned to that BU for each object (like Departments, Jobs, Locations, etc.). Just observe this relationship. This is the heart of data partitioning in Fusion.

Why This Matters

Understanding Reference Data Sets is a huge step. It's the "hidden" layer that gives you true control over your configuration. It is how you manage a complex, global company without showing everyone, everything, all the time.

Now that we know how to build our organization (BUs) and how to control the data they see (RDS), we are finally ready to create the actual blueprints for work. In our next post, we will do just that as we explore Jobs and Positions.