Workday / Guide: ID strategy and usage

Objective

• To provide information on how IDs will be used and stored in Workday

Environment

• 1191721: Workday

Guidelines

Types of IDs

As Workday becomes the primary ERP for Miami, the following IDs will be available for general use to identify people within Workday:

• Workday Account (UniqueID)
  • This is the value we currently call the UniqueID, which is generated for all Employees and Students at Miami, and is used for signing in to Workday
  • To be used by humans and (in limited cases) system integrations
  • An initial value will be generated by a Workday sequence (for example firstname.lastname)
  • The final ID (in the format of Unique ID) will be generated by the IAM system and stored in Workday, overwriting the initial value generated by Workday
• Workday Universal ID
  • This value will be synced to Workday Employee ID and Workday Student ID
  • To be used primarily for business processes and integrations
  • While the Workday Universal ID can be easily discovered by individuals, it is not expected that individuals will know or need produce this ID value for themselves as a validation for any reason
  • This ID will be generated by Workday

Workday Universal ID specifications

The Workday Universal ID will be generated using the following rules:

• 8-digit number
• Sequentially generated starting with 10816446 and incremented by 1 for each new person (i.e. first person would be 10816446, second person would be 10816447, etc.)
  • The starting number 10816446 was selected to avoid "employee 1" concerns which may arise from starting at a round number
• The Universal ID will be synchronized with other person IDs within Workday. In other words, the Employee ID, Student ID, etc. will be populated with the same value as the Universal ID for each person

Alternate IDs (synced between systems)

• The following IDs will be stored in Workday as alternate IDs as long as those IDs continue to be generated:
  • Banner Plus Number
  • PIDM
  • Advancement ‘A’ Number
  • UDC ID (needed for authentication to Banner)
     
• The following IDs will be stored in Banner as an alternate ID until Banner is decommissioned:
  • Workday Universal ID
     
• The following IDs are stored in Workday to be used in integrations. Workday is not the authoritative source:
  • aptiQ
  • Apple phone ID
  • Android phone ID
  • Smart Card ID
  • Apple Watch ID
     
• The following IDs will not be stored in Workday as alternate IDs:
  • No Banner+ Number variations will be stored in Workday (IDs that have replaced the + with an ‘8’, ‘9’, ‘M’, etc.)
  • Only the current Banner+ Number will be stored in Workday for each individual. For those individuals where a new Banner Plus Number was generated in the past, the inactive Banner+ Number will not be stored in Workday

Note: Banner+ Number and PIDM will be phased out for new employees and students. An exact timeline has not been established for this phase-out but will most likely not extend beyond Fall 2026 at the latest.

Sensitivity for Workday Universal ID

The Workday Universal ID should be considered ‘Internal Only’ for data classification purposes (refer to the Miami University Data Classification best practices for information on data classifications). The Workday Universal ID should not be used as the sole method for verifying someone’s identity in the context of providing services such as Miami network account recovery or Personnel Office use in releasing sensitive information about the person from Workday data. Instead, some official form of photo identification should be used.

Addendum A: Updated Workday Universal ID Value

Miami's original Workday Universal ID value was a 10-digit number based on a Workday sequence. The sequence initial value was to be 1110816446. Prior to applying updated IDs in our tenants, the integration team discovered two cases in which vendors limit the ID value to 8 characters. 

After reviewing the options, we have decided to reduce the Workday Universal ID pattern from 10 digits to 8 digits (the length is arbitrary and 8 digits achieves the same outcomes). The new starting value will be 10816446.

We selected 8 digits to prevent potential confusion with SSN values which are also 9 digits. A 9 digit Workday ID would potentially be confusing not only for humans, but also trigger false positives during automated data leakage scans run by ISO.

Addendum B: Reservation of ID values for Student ID generation

The Workday Student implementation project identified the need for Miami to generate final, persistent Workday Student IDs for all students being converted to Workday. This includes active and historical student records. In order to prevent conflicts as new employees are hired, we chose to manually advance the Employee ID generator to create a gap in the ID sequence sufficient to encompass all anticipated student records. On October 10, 2024, the generator was advanced from 10829458 to 12829458. The generator began creating new IDs beginning with 12829459, leaving the range from 10829459 to 12829458 available for the Student data conversion effort. We do not anticipate using all values in that range and expect there to be a significant number of values which will never be assigned as a Workday ID.

Change Log

September 10, 2024: Updated to reflect that Banner UDC ID will be stored in Workday due to the need for RapidIdentity to access it as part of employee data. It was previously listed as not being stored in Workday.

September 10, 2024: Updated to reflect that "mobile credentials" (smart card, phone, watch) IDs from CSGold will be stored in Workday. These are managed by RapidIdentity and are used in integrations such as the Library Patron Extract. These were previously listed as not being stored in Workday.

Background

The remainder of this document is a recording of part of the discussions that led to the proposal above.

Miami has fundamentally two options regarding IDs in Workday. We can reuse Banner identifiers as identifiers in Workday as part of our conversion or we can have Workday generate new identifiers unique to Workday. [Note: While it is possible to mix these two approaches into a third blended option, we believe that would simply increase confusion and should be avoided].

Recommendation: We recommend the path of having Workday generate our new identifiers and retain the legacy values as alternate IDs linked to the appropriate Workday person record. While this approach will require some short term consideration for integrations, we believe it minimizes complexity during the dual ERP portion of our conversion and offers the best long term benefits for ID management.

Rationale/Decision Factors: Unique identifiers (per person) are critical within an ERP. Banner currently generates the "Banner ID" (aka Banner+ Number) as the primary public identifier for a person and PIDM as the internal identifier. Workday has a number of public identifiers which will be used in similar ways, for example, an Employee ID, a Student ID, a Universal ID, and a Workday Account (used for SSO login to the system). Miami has some control over many of these identifier types and we must consider our experience with the legacy Banner IDs, the interim period of using both ERPs and our long term needs when making this identifier decision.

During the consideration process, we must remember that:

• Both Banner and Workday must be authoritative for their own IDs 
• Both Banner and Workday must know the opposing ERP IDs for shared users
• New people will be added to both ERPs (as applicable) in the time between Platform and Student go-live
• Some users (faculty, student employees, employees taking classes) must be present in both ERPs
• Miami has had technical issues with the '+' sign in Banner IDs as well as leading zeros when the ‘+’ sign was stripped away during integration activities
• External systems may use Banner ID or PIDM as an identifier
• Miami UniqueIDs are managed outside of the ERP and must be used as the Workday Account value.
• Eventually Banner is going to be no longer in use
   

Identified benefits and risks associated with each of the two proposed approaches.

• Reuse Banner identifiers as identifiers in Workday
• Benefits if we choose this option
  • Known IDs can be used when looking up other people in the system
  • Some integrations will be easier to keep consistent
• Risks if we choose this option:
  • Complexity in keeping the two systems aligned as people are added to each
  • Complexity with faculty, student employees and staff taking classes as they cross systems
  • Currently, we have some integrations with other systems that substitute the plus sign with a number 8 and would need to continue in the integrations if we opt for this method
  • Some integrations use PIDM rather than Banner ID and this approach will not solve that problem
  • Banner ceases to be used within 3 years (at the conclusion of the Student portion of the implementation project)
     
• Have Workday generate new person identifiers unique to Workday
  • Benefits if we choose this option
    • Lower complexity managing people and IDs between Banner and Workday until Banner is phased out completely
    • Use of leading practices (no special characters) in identifiers
    • The identifier value is less necessary when searching for a person in Workday since the name or other text fields such as UniqueID will get you to the applicable record easier than searching on the identifier value
    • Opportunity to move away from the '+' character in the ID and escape the technical debt of this long-standing practice designed over 20 years ago
  • Risks if we choose this option
    • Integrations until full go-live may need to include Banner ID as a primary key (which is available as an alternate ID ‘loaded’ into WD) 
       

What to expect with the proposed option 2:

1. In Workday, Banner IDs will be added as alternate IDs for any people also found in Banner
2. In Banner, the various Workday identifier values will be added as alternate IDs for any people also found in Workday
3. Newly created people in Workday will have a Workday Account (username) which does not match UniqueID expectations, this Workday Account value will be replaced when the Identity system generates a proper UniqueID for a newly created person - this is applicable now for employees and in the future for students. It is expected that this should be a real-time integration from Workday to the identity system.
4. After HR functions have transitioned to Workday, new employees should NOT be created through Banner Admin forms, only the Workday integration process should create new person records in Banner as needed (ie, employees needing to be added to courses as the instructor of record, etc).
5. Banner Plus numbers will cease to be created upon our full transition to Workday