Unique record IDs for Foundation data
As an administrator, when you create Foundation data elements or load existing Foundation data from Remedy ITSM, BMC Helix Platform automatically generates unique record IDs. A unique record ID helps to identify a record internally in an application. It also helps to move any application data that is associated with Foundation data from one environment to another environment. However, this movement of data is possible only if both environments have the same Foundation data. For example, if environment 1 has category tier Hardware, ensure that environment 2 also has category tier Hardware.
A unique record ensures that the ID of a record is the same, regardless of the environment from you load Foundation data.
How a unique record ID is generated
BMC Helix Platform automatically generates a unique record ID for Foundation data elements such as Location, Categorization, Organization, and Person. After a unique record ID is generated for a Foundation data element and you delete the element, BMC Helix Platform can generate the same unique record ID for that element. This behavior is applicable only to Location, Categorization, and Person Foundation data elements, and if you create the Foundation data element with the same name.
The following table lists the criteria for generation of a unique record ID for each Foundation data element:
| Foundation data element | Criteria for generation of a unique record ID |
|---|---|
| Location | The following list provides the criteria for unique record ID generation for different types of location:
|
| Categorization | Categorization name, related category ID (parent category tier), and category type (Root cause category, Product category, Operational category, and Resolution category) |
| Organization |
|
| Person | Login ID, employee ID, first name, preferred name, middle name, last name, primary email address, primary phone number, and primary extension |
Example of generation of a unique record ID
Consider an example where you create the following product category tiers:
- Category Tier 1—Hardware
- Category Tier 2—Server
- Category Tier 3—Linux
The following table describes how the unique record IDs are generated for each category:
| For category | The unique record ID generated is based on |
|---|---|
| Hardware | Hardware (category name) + Product category (category type) + Null (Because Hardware has no parent category) Consider the unique record ID generated for Hardware as ab1. |
| Server | Hardware (category name) + Product category (category type) + ABC (Unique record ID of the parent category Hardware) Consider the unique record ID generated for Server as pq2. |
| Linux | Hardware (category name) + Product category (category type) + PQR (Unique record ID of the parent category Server) Consider the unique record ID generated for Linux as xy3. |
In this way, a unique record ID for each category is generated.
Effects of updating Foundation data after a unique record ID is generated
A unique record ID is not generated for Foundation data that you update. For example, consider the following events that take place:
- You create the following product category tiers:
- Category Tier 1—Hardware
- Category Tier 2—Server
- A unique record ID for Category Tier 2 is created based on its name Server, the parent category Hardware, and the category type.
- You change the name of Category Tier 2 from Server to Servers.
In this scenario, the unique record ID for Category Tier 2 is not generated again.
Comments