Key concepts

System reference data contains a group of values that provide information about your reference data. For new organizations, values for the system reference data are empty.

You can add the values that you want to appear in the system reference data. The users can then apply the values to their reference data sets, code lists, code values, and crosswalks. For example, you might add the Low, Medium, High, and Critical values to the Priority system reference data.

You can add values to the following system reference data:

Reference data sets

All reference data in Reference 360 is categorized under reference data sets. A reference data set is a logical grouping of reference data, such as country codes, currency codes, or cost centers.

Reference data sets contain code lists. Reference data sets act as both a container and template for the code lists.

When you create a reference data set, you configure its structure definition and attributes. You cannot change the structure definition and attributes of the reference data set after creation. When you add code lists to a reference data set, the code lists inherit the structure definition and attributes from the reference data set. If you do not define the structure definition of a reference data set, you can still define the structure definition of the code lists.

The following table lists the actions you can perform on a reference data set after creation:

Action	Allowed
Delete the reference data set	Yes
Modify the general properties	Yes
Modify the structure definition	No
Modify existing attributes	No
Create additional attributes	Yes
Create required attributes	Yes
Delete attributes	Yes
Modify the display settings	Yes
Modify the stakeholders	Yes

For example, you might have three different applications, each with a slightly different list of country codes. In Reference 360, you create a Country Codes reference data set. Then you create three code lists in the Country Codes reference data set, one for each of the applications that contain country code values. The last step is to create crosswalks between the code lists so that you can translate how each application represents the same code value.

Hierarchical reference data sets

A hierarchical reference data set allows users to model hierarchical data structures. When you create a code list in a hierarchical reference data set, the code list inherits the hierarchical structure definition. In the code list, you can arrange the code values into levels to create hierarchies. For example, you might create a hierarchical reference data set for industry classification systems or cost centers.

After you create a hierarchical reference data set, you cannot change the structure definition. If you create a code list in a hierarchical reference data set, the code list must use the inherited structure definition.

For example, you want to create an Industry Classifications reference data set. When you create the set, you define the structure definition as hierarchical because you know that industry classifications contain hierarchical code values. In the reference data set, you create an Enterprise Industry Classification code list, a NACE code list, a SBI code list, and a NAICS code list. In the NAICS code list, you arrange the code values into a hierarchy to reflect the hierarchical structure of this externally mandated list.

Dependent reference data sets

When you configure a reference data set as dependent, the reference data set that it depends on is referred to as the parent dependency. Reference data sets can have only one parent dependency. When you create code lists in a dependent reference data set, the code lists inherit the same parent dependency.

After you create a dependent reference data set, you cannot change the structure definition. If you create a code list in a dependent reference data set, the code list must use the inherited structure definition.

For example, you have a Country Codes reference data set. When you create a State Codes reference data set, you define the structure definition as dependent and configure the Country Codes reference data set as the parent dependency. Then when you create code lists in the State Codes reference data set, the code lists inherit the dependency on the Country Codes reference data set. For each code list in the State Codes reference data set, you can choose the code list dependency. A code list dependency defines the dependent relationship between one code list and another. You might want the Enterprise State Codes code list to depend on the Enterprise Country Codes code list.

Code lists

Code lists are containers for code values. The code values in a code list reflect the code values that are used in a source application. Code lists from different applications might use different code values for the same business term.

A code list inherits the structure definition and attributes from the reference data set. If a reference data set does not have a structure definition, you can configure the structure definition of the code list.

You can provide additional details for a code list, such as additional description, external URLs, and notification recipients.

The following table lists the actions you can perform on a code list after creation:

Action	Allowed
Delete the code list	Yes
Modify the general properties	Yes
Add external URLs	Yes
Modify external URLs	Yes
Delete external URLs	Yes
Add notification recipients	Yes
Modify notification recipients	Yes
Delete notification recipients	Yes
Modify the inherited structure definition	No
Modify the inherited attributes	No
Create additional attributes	Yes
Create required attributes	Yes
Delete attributes	Yes
Modify the display settings	Yes
Modify the stakeholders	Yes

For example, you might have a Country Codes reference data set to categorize all the country codes used in your organization. This reference data set might contain an Enterprise Country Codes code list for country code values that your organization uses for enterprise reporting. You might also have code lists for industry standard lists of values, such as ISO Country Codes and IANA Internet Country Codes. You might also have code lists for systems that store similar code values, such as country codes in your CRM system.

Hierarchical code lists

If you create a code list in a hierarchical reference data set, the code list inherits the hierarchical structure definition from the reference data set. If you create a code list in a reference data set without a hierarchical structure definition, you can configure the structure definition of the code list as hierarchical. After you create a hierarchical code list, you cannot change its structure definition.

For more information about actions that are allowed after code list creation, see Code lists.

For example, you have an Industry Classification reference data set that does not support hierarchical data structures. If you need to create a NAICS code list in the reference data set that supports hierarchies, you configure the structure definition of the code list as hierarchical.

Dependent code lists

A dependent code list contains code values that depend on code values in another code list. The dependency exists between code lists that belong to different reference data sets.

If you create a code list in a dependent reference data set, the code list inherits the parent dependency from the dependent reference data set. If you create a code list in a reference data set without a dependent structure definition, you can define the code list as dependent. After you create a dependent code list, you cannot change the dependency.

For more information about actions that are allowed after code list creation, see Code lists.

Code values

A code value is a unique value, such as a business term, code, or lookup value. Code values are organized into code lists. Each code list contains code values from a singular source application or industry standard list.

For example, you might have a Country Codes reference data set, and within it is an Enterprise Country code list. In the Enterprise Country code list, you import enterprise country codes values that your organization uses for enterprise reporting. The code list includes code values such as Afghanistan, Aland Islands, and Albania. You might also have a ISO Country Codes code list, a CRM Country Codes code list, and a IANA Internet Country Codes code list. Each of these code lists contain their own code values.

Code values consist of attributes. Each code value consists of a Name attribute and a Code attribute. For example, you might create a code value for the US country code. You define the Name attribute as US and the Code attribute as 001. For more information, see Attributes.

Crosswalks

A crosswalk is a visual representation of a one-way relationship between code values in a pair of code lists. A reference data set can contain many code lists, and each code list contains a variation of the same type of code values. Crosswalks provide a way to translate between the different variations each code list uses.

You can create crosswalks for code lists that belong to the same reference data set or different reference data sets. When you create a crosswalk, you configure a source code list and a target code list. You create one-way value mappings between code values in the source code list and code values in the target code list. Value mappings provide a way to translate the code values in the source code list to code values in the target code list. The crosswalk and the value mappings are associated with the source code list.

If code values in a pair of code lists are equivalent, you must create two crosswalks. When you create the crosswalks, use the same pair of code lists in reversed order as the source and target code lists. You must create two crosswalks because each code list can be used as a source code list and crosswalks are stored with the source code list. You cannot create multiple crosswalks for the same source and target code lists.

For example, your organization might have a Country Codes reference data set with code lists for enterprise country codes and ISO country codes. You might create the following crosswalks to map code values in the code lists:

After you create a crosswalk, the crosswalk is associated to the source code list as an outgoing crosswalk and to the target code list as an incoming crosswalk. Use the Explore panel to view code lists and the associated outgoing and incoming crosswalks. An outgoing crosswalk appears below the source code list and shows the source code values that map to the target code values. An incoming crosswalk appears below the target code list and shows the source code values that map to the target code values.

The following diagram shows a sample crosswalk:

Hierarchies

After you create reference data sets, code lists, and code values, you can create hierarchies. A hierarchy shows how code values are related to one another. You can arrange code values above, below, or at the same level as other code values.

Code values in a hierarchy are top-level nodes or child nodes. Each hierarchy must contain at least one code value as the top-level node. Top-level nodes are code values at the highest level in a hierarchy and don't have any code values above them. Child nodes are arranged below other code values and can have other code values below them.

The hierarchy relationships that you can create depend on the hierarchy model. A hierarchy model consists of hierarchical relationships between code lists. You define a code list as the top-level code list and then define levels by adding code lists and relationships between the code lists. Then based on the hierarchy model, you can add code values as nodes in the hierarchy.

For example, your organization needs to track country codes by regions. You might create the following hierarchy model:

The following image shows a sample hierarchy model:

With the hierarchy model defined, you might create the following hierarchy:

The following image shows a sample hierarchy:

The relationship between the code values in a hierarchy are termed as related code values.

For example, in the preceding sample hierarchy, the Regions code list contains two code values, such as North America and South America; and the Enterprise Country Code code list contains two code values, such as Canada and USA. In the hierarchy model, the hierarchical relationship connects the two code lists, and the code values in the parent and child code lists are related to each other.

Attributes

An attribute is a component of a code value. When you create reference data sets and code lists, you define attributes that code values must consist of. Then when you add code values, you enter a value for each attribute.

By default, the attributes defined for all code values are the Name, Code, and Description attributes. The Name and Code attributes are required attributes, so you cannot delete these attributes. For each code value, you must enter a value for these attributes. The Description attribute is not required, so you can delete the Description attribute if you do not need it.

For example, you might have a code list for Enterprise Country Codes. When you add a code value for the US country code, you enter the United States of America value in the Name attribute. You enter the US value in the Code attribute. This means that the US country code value consists of the United States of America and the US attribute values.

The following image shows the Enterprise Country Codes code list with values in the Name attribute and Code attribute for each code value:

You can set default values for predefined and custom attributes in a code list. When you set a default value, you don't have to add the same set of values multiple times.

For example, if you have to add the office location for all the employees in the Employee Details code list, you can add the office location as a default value for the Location attribute. When you add code values, the Location attribute displays the default value.

Custom attributes

When you create a reference data set or code list, you can create custom attributes and define them as required or optional. If you define custom required attributes for reference data sets, the code lists inherit the attributes from the reference data set. Then when you create code values in the code lists, the code values must contain values in the custom required attributes. Also, when you create code lists, you can configure custom required attributes in addition to the inherited attributes from the reference data set.

Note: You can only define custom required attributes when you create a reference data set or code list. For more information about allowed actions, see Reference data sets and Code lists.

For example, you create a Country Codes with Currency code list. You create the optional Population and Currency custom attributes. When you create code values in the Country Codes with Currency code list, you must enter values in the required Name and Code attributes. You can choose to enter values for the Population and Currency attributes.

The following image shows an example of the attributes defined for the Country Codes with Currency code list:

The following image shows an example of the attribute values for code values in the Country Code with Currency code list:

Attribute data types

When you configure custom attributes, you can define data types for the attribute values.

You can configure data types, such as string, integer, decimal, date, boolean, and reference data. You can define a scale for decimal data type attributes. The default scale is 4. When you add an integer data type, the minimum value is -9223372036854775808, and the maximum value is 9223372036854775807. When you define reference data as the data type, the values depend on the referenced reference data asset.

The Reference Data data type supports lookup reference data. Use the Reference Data data type to include the code values from another reference data set and code list. For more information, see Reference data attributes.

Reference data attributes

You can create custom attributes that support reference data from other assets. These reference data attributes allow you to use code values in other assets as an attribute value for code values in the code list.

When you create reference data attributes, you configure the reference data set and code list that you want to use reference data from. You also specify the attributes that you want to appear as the display attributes to represent the code values from the selected code list and reference data set.

If you don't specify a reference data attribute as a required attribute, you can leave the reference data attribute empty when you add code values.

The following image shows the Currency attribute configured as a data type - Reference Data:

The following image shows an example of the code values in the Enterprise Currency code list that are used as reference data attributes:

When you add code values to the Country Codes with Currency code list, you can select reference data in the Enterprise Currency code list to use as the Currency attribute value.

The following image shows the Euro - EUR - Euro code value from the Enterprise Currency code list used as the Currency attribute value of the Andorra code value:

When the reference data set and code list of a reference data attribute depend on the code list of existing reference data attributes, you can set dependency between them.

For example, to manage the employee details, your organization has added the Employee Details code list. The details include the birth and work locations of the employees.

If John was born in Ontario and works in Bavaria, you can add reference data attributes, such as Continent of Birth, Country of Birth, State of Birth. To add the details of the work location, you can add similar reference data attributes.

Your organization has defined reference data sets, such as Continent, Country, and State. The State reference data set depends on the Country reference data set, and the Country reference data set depends on the Continent reference data set.

After you add the Continent of Birth reference data attribute, you can add the Country of Birth reference data attribute. When you add the Country of Birth reference data attribute in the Employee Details code list, you can view its dependency with the Continent of Birth reference data attribute. You can select the Continent of Birth on the Dependent On field.

The following image shows the dependency set for the reference data attributes in the Employee Details code list:

When you add the employee details for John, if you select North America as the Continent of Birth, the Country of Birth reference data attribute displays only the countries added to North America.

If you select Europe as the Continent of Work, the Country of Work reference data attribute displays only the countries in Europe.

You can view the values because there's an existing dependency between the code values in the code list.

Display attributes

Display attributes are the attributes that represent the code values in the asset throughout Reference 360. You configure display attributes for reference data sets and code lists. You can configure multiple attributes as display attributes.

For example, code values in the Country Code with Currency code list might consist of the Name, Code, Description, Population and Currency attributes. You can configure the Name attribute as the display attribute. Later when you create a crosswalk to map code values in the code list, the attribute values in the Name attribute appear for you to map.

The following image shows an example of the values in the Name attribute that represent the code values in the code list:

Batch Jobs

The batch jobs use the taskflows defined in Cloud Data Integration. Each taskflow can run multiple mapping tasks in a sequential order or in parallel. Each mapping task includes a mapping that maps the source fields with the fields of the Reference 360 assets. To connect to the Reference 360 assets, use the Business 360 connector, and create a connection in Administrator.

For example, if you want to import enterprise country codes from a flat file, create a mapping with a flat file connection as the source transformation and the Business 360 connection as the target transformation. You can then define field mappings between the source and target fields, create a mapping task that uses the mapping, and then create a taskflow and run the taskflow. For more information, see Taskflows in the Data Integration help.

Use Administrator to create a connection for the source transformation and a Business 360 connection for the target transformation. For more information about the Business 360 Connector, see Business 360 Connector in the Data Integration help.

Workflows

When you propose changes to a code list, a crosswalk, or a hierarchy, you can send the changes for approval through an approval workflow. An approval workflow consists of one or more linked approval tasks to review and approve your changes.

To propose changes, you can lock the code list, crosswalk or hierarchy. When you lock the code list, the crosswalk or the hierarchy, a draft version is created and you prevent other users from making changes. You can import, create, update, or delete code values in a code list, value mappings in a crosswalk, and create, update, or delete parent or child code values in a hierarchy. Your edits remain in the draft, and you can choose to continue editing later. The presence of a lock icon beside the code list, the crosswalk, or the hierarchy indicates to other users that you are working on it.

After you finish editing the code list, the crosswalk or the hierarchy, you can send your draft for approval. This action triggers an approval workflow and generates an approval task. Users responsible for approving the task receive notifications. As the code list, the crosswalk or the hierarchy progresses through the approval workflow, it remains locked.

Note: To use workflows, you must add values to the Priority system reference data. For more information, see Adding values to system reference data or Add system reference data values.

Users assigned the following roles can send their proposed changes for approval or directly publish their changes without approval:

For more information about roles, see Users, groups, and roles

Notifications

When users send an approval request, cancel an approval request, or perform a task action, the users responsible for the asset receive a notification. The notification alerts users that a change requires their review, a review is no longer required, or that a task action was performed by another user. Notifications appear in the user's inbox and in an email notification.

The following table lists which users receive inbox notifications following task events:

The following table describes the email notifications users receive following task events:

Event	Requester	Assignees
User assigns a task	-	Yes
User approves, rejects, or sends back a task	Yes	-

Event	Requester	Assignees
User sends approval request	Notification confirms that they successfully sent the approval request.	Notification of approval request that requires their review.
User cancels approval request	Notification confirms that they successfully canceled the approval request.	Notification of canceled approval request that no longer requires their review.
User approves, rejects, or sends back a task	Notification of the action performed on the approval request.	The assignee who performed the action receives a notification that confirms their action. All other assignees receive a notification that another user performed an action on the approval request.

Tasks

Tasks are requests to review and approve changes to code lists, crosswalks, and hierarchies. A task is created when a user sends their draft code list, crosswalk, or hierarchy for approval. Tasks are assigned to users who are responsible for reviewing and approving changes to the code list, crosswalk, or hierarchy. A task helps to manage changes to the code list, crosswalk, or hierarchy.

Use the Workflow Inbox tab to view and take actions on tasks. You can also send your draft code lists, crosswalks, or hierarchies for approval.

The Workflow Inbox tab consists of a Task panel and a Task Details panel. Use the Task panel to view all tasks available to you. In the Task Details panel, view the details of a task that you selected, compare the proposed changes against the active version, and take action on the task.

You can view the following task details:

Versions

As an asset moves through a workflow, different versions of the asset are created. The version that is available depends on where the asset is in the workflow.

When you view an asset, you are viewing the active version of the asset. To propose changes to an asset, you create a draft version of the asset. When you are done making changes, you send your draft for approval. If approved, the draft version becomes the active version. If rejected, the draft version is discarded and the active version of the asset is available.

When you view an asset that was sent for approval, you can see the changes pending approval. You can compare the pending changes with the active version. If you are the last reviewer responsible for approving the draft, you can approve the changes while viewing the pending changes.

The following table describes the available versions for an asset:

Version	Description	Available to
Active	Active version of the asset that contains approved reference data.	All users viewing an asset without proposed changes.
Draft	Draft version of the asset that contains proposed changes.	Users proposing changes to an asset.

If you are a reviewer, you can compare the draft version and active version to see moved, deleted, and added reference data. For more information, see Comparisons.

Comparisons

You can compare the draft version of a code list or a crosswalk with the active version to compare proposed changes with the active version. You can also compare code lists and hierarchies to identify similarities and differences.

Compare changes

You can compare the draft version of a code list or a crosswalk with the active version. You can view the changes to code values and value mappings and evaluate whether the changes are correct. You can compare versions when you work on a draft, send a draft for approval, or review an approval task.

The Compare Versions view displays both unchanged and changed code values in a code list and value mappings in a crosswalk. When you edit or review a draft, you might want to view only changed code values or value mappings. You can also filter to view added, edited, moved, and deleted code values or value mappings only.

When you compare moved code values, you can navigate to the new location of the moved code value. You can navigate back to the original location to evaluate whether the move to the new location is correct.

The following table lists the changes to code lists and crosswalks and the highlights:

Change in a code list	Change in a crosswalk	Highlight
Deleted code value	Removed value mapping	Red
Edited code value	-	Yellow and italicized
Moved code value	-	Blue
New code value	New value mapping	Green

The following image shows an example of the Compare Versions dialog box that appears when you compare your draft with the active version in the new visual experience:

The following image shows an example of the Compare Versions dialog box that appears when you compare your draft with the active version in the classic experience:

The following image shows the Compare Versions section of a task:

Compare lists

You can see a side-by-side view of code lists and hierarchies to identify similarities and differences between code values. You can choose to compare the same or different types of assets. For example, you might want to compare the code values in a code list with the code values in another code list, or the code values in a code list with the code values in a hierarchy.

To use the side-by-side view to display the information that you want to compare, perform the following tasks:

The following image shows a sample comparison between the Enterprise State and Enterprise Country code lists in the new visual experience: A side-by-side comparison of the Enterprise State and Enterprise Country code lists.

A side-by-side comparison of the Enterprise State and Enterprise Country code lists.

History

The History tab displays a log of changes to an asset or code value. You can view historical information about a reference data set, a code list, a crosswalk, a hierarchy, or a code value.

When you view the History tab, you can see the following information:

Asset	Historical information
Reference data set	Changes to properties, status, and definition.
Code list	Changes to properties, status, definition, and code values
Crosswalk	Changes to properties, status, definition, and value mappings.
Code value	Changes to the code value.

The History tab displays the following historical information:

The following image shows an example of the History tab for a code list:

Relationships

You can view relationships between code values in code lists, crosswalks, and hierarchies. Use the Relationships tab to view the relationships for a code value in a graph.

The following table lists the relationships that the graph displays:

Asset Type	Relationships
Dependent code list	The code value that the selected code value is dependent on. The dependent code values of the selected code value.
Hierarchical code list	The parent code value of the selected code value. The child code values of the selected code value.
Crosswalk	The code value that the selected code value is mapped to. The code value that the selected code value is mapped from.
Hierarchy	The parent code value of the selected code value. The child code values of the selected code value.

The following image shows the relationships for the USA code value:

Data quality rule associations

Create data quality rule associations to ensure that code values meet your business standards. A basic rule association is based on a simple condition-based rule. An advanced rule association is based on a Cloud Data Quality rule specification. You can create basic and advanced rule associations for string, integer, decimal, date, and reference data attributes of code lists, and advanced rule associations for boolean attributes of code lists.

When users add or edit code values that do not meet your business standards, they receive inline validation errors.

For example, in the Country Codes code list, you might want the Code attribute to require a minimum of three characters. When users create code values in the code list, if they enter the USA value in the Codes attribute, then the value is valid. If they enter the US value, then the value is invalid and they receive inline validation errors.

For example, in the Health Insurers code list, you might have the Name, Code, and Third-Party Administrator attributes. You configure a concatenate rule for the Code attribute to populate the Code attribute with the values in the Name and Third-Party Administrator attributes. If the Name attribute value is Acme Inc. and the Third-Party Administrator attribute value is General Insurer, the value populated for the Code attribute is Acme Inc., General Insurer.

Warning: If you create or edit rules for a code list containing code values, some of the code values might become invalid. To find the invalid code values, edit each code value to trigger a validation check.

You can search for reference data in your organization and filter the search results by reference data sets, code lists, code values, or hierarchies. The search results are grouped into tabs by asset type. The hierarchy details are not available for users with a Reference Data Management Basic Edition license.

Use the search box in the application header to perform a keyword search. Any reference data that match the keywords appears in the search results.

When code values appear in the search results, you can open the code lists and reference data sets that contain the code values from the search results.