Workday / Guide: Use of Miami IDs

Objective

• To provide information on using and viewing the various Miami IDs in Workday
• To provide information on searching for users using various IDs in Workday
• To provide information on using IDs in reports and integrations in Workday
• To provide information on creating and changing ID values in Workday

Environment

• 1191721: Workday

Guide

Miami constituents are identifiable by several associated values in addition to the Workday ID (Employee ID, Student ID, etc) in Workday. The Workday ID will be a long numeric value that is not expected to be memorized or readily retrievable by the majority of people. (The authoritative source for this value will be the Workday Universal ID and that value will be synced to Employee ID, Student ID, etc.)  In order to facilitate finding and identifying people, Workday will include a number of legacy and external system identifiers.

While these other IDs are searchable, viewable, and usable in reports and integrations, security restrictions will impact the ability of any individual to search by or view other ID values.

 

IDs in Workday

Workday Account (username)

Every user in Workday has a "Workday Account" identifier. This value is the username that will be referenced during single sign on. For Miami users, the Miami UniqueID will be used as the Workday Account.

 

Other IDs

The Other IDs associated with a user can be viewed from a person's profile and selecting Personal and then the IDs tab. The IDs of interest for identifying people or commonly used in reports or integrations include, but are not limited to the following.

Not all users will have all listed values and IDs in addition to those listed here may be present.

 

Search for users using IDs

Any ID associated with a person may be used to find them via the Workday search function. Searching is subject to security controls, so only people with permission to see the ID values will be able to use them in searching.

 

Workday Account (username)

The Workday Account is a default search value when using the Workday search function. To find a person using their Miami UniqueID, simply enter the UniqueID in the search box (case does not matter); example: publicjq.

 

Employee ID

Searching by Employee ID requires an additional security domain, "Search: All Workers by Worker ID", which was not part of our initial security configuration. This will need to be added to any security roles identified as eligible to search by Employee ID. As currently configured, HR and Payroll users are listed in the domain, allowing those users to search by Employee ID.

 

Student ID

Student ID security is different from Worker ID security. Workers have the additional layer of security that requires users to be assigned to the Search: All Workers by Worker ID domain to search by the ID. Students do not have this layer of security. As long as the user can access the Student ID, they can also search by it. Workday will likely update this in the future so that security for both person objects is in sync. However, they do not have it currently listed on the roadmap.

 

Other IDs

When searching for Other ID values in Workday, you can still use the Workday search function, but you must include the "id:" prefix; example: id: +0012345.

Note that searching by UniqueID works with or without the "id:" prefix because the UniqueID value is included as both the Workday Account and the Other ID.

 

Use of IDs in reports and integrations

The Other ID values for Worker, Student, and other objects will be used through calculated fields associated with that object type. These calculated fields should be global for the object type and the name should reflect both the business object and ID. Creating multiple calculated fields on the same business object as a means of accessing the same ID value is highly discouraged.

Refer to the Workday guides for naming standards and best practices for the specifics of naming calculated fields.

For example, the following calculated fields have been created on the Worker business object:
 

Considerations when choosing an ID

Reports and integrations often need a unique identifier for each person. For the purpose of identification, the Workday ID (Employee ID, Student ID, etc) is preferred and sometimes required depending on the Workday web service being used. This is a unique value managed by Workday.

The Miami UniqueID may be preferred in some cases. For example, report consumers may wish to see a more recognizable value to facilitate identification in their business process. The target system of integrations may require the UniqueID to support authentication through our identity system. There is no rule against using UniqueID in these cases, but stakeholders must understand that it is not uncommon for people to request changes to their UniqueID. While the value is guaranteed to be unique, it is NOT guaranteed to be unchangeable. Each report and integration use case should consider the consequences of changing identifiers.

Most of the "Other ID" values in Workday are either legacy or intended for very specific use cases. For example, Banner ID will be maintained in Workday until we are fully migrated from Banner in order to support existing integrations. Other IDs relate to devices to support tap and similar functions and should not be used for unapproved purposes. 

Users are encouraged to use business object reports (i.e., searching “BO:” followed by the business object name (e.g., BO: position)) when determining which ID fields to use in custom report and integration development. These reports will help identify which ID fields are available on the business object. ID fields not listed on the business object will require calculated fields to bring the information to the business object, which in turn, will increase overall system maintenance and decrease system performance. 

 

Transition from legacy IDs to Workday IDs

Miami's transition from Banner to Workday will result in the discontinuation of IDs generated by Banner, of which Banner ID (aka "Plus Number") is the most significant. Many reports and integrations include Banner ID and business processes associated with those reports and integrations may be impacted by changes. 

There is no single solution to these scenarios. The following factors should be considered when deciding how to approach any report or integration.

 

During Workday Platform implementation

The primary concern during the build phase prior to our July 1, 2024 go live of Workday Platform is to ensure continuity of integrations with external systems. Planning for minimal changes during our implementation is one way to reduce risk. Where possible, the first choice should be to continue sending the current ID value for the integration. For example, if an integration is currently using Banner ID as the identifier, that same integration in Workday should continue using Banner ID.

There will be a bi-directional integration between Workday and Banner for employee data. Newly hired employees in Workday will be sent to Banner where a Banner ID will be generated. The Banner ID will be sent back to Workday and stored as an "Other ID" consistent with our data conversion.

If the vendor is willing to undertake an ID conversion as part of our implementation, the change can be pursued as part of the go-live. 

Integrations including student IDs should continue using legacy IDs from Banner until the move from Banner Student to Workday Student is complete.

 

During mixed ERP usage

After implementing Workday Platform, we will begin transitioning individual integrations from legacy IDs to Workday IDs. Any employee record included in an integration should use a Workday ID (or if appropriate, the Miami UniqueID or other acceptable value) before the move from Banner Student to Workday Student is complete.

As Student integrations are implemented in Workday, the change from legacy IDs to Workday IDs should be incorporated into the design and migration plan.

 

After full Workday implementation

After the transition from Banner Student to Workday Student is complete, we will stop generating new legacy Banner IDs for new employees and students. At that point, all reports and integrations should be using Workday IDs or have a sustainable implementation for IDs.

 

Create and change ID values

Workday is the authoritative source of Employee ID, Student ID and other ID values generated within Workday. Other ID values are created and maintained outside of Workday and therefore should only be changed in Workday under specific circumstances.

 

Workday Account and Miami UniqueID

The Miami UniqueID is created and managed by Miami's identity system. When a new person object is created in Workday, Workday will generate a temporary Workday Account and send a request to the identity system. The identity system will generate a UniqueID and push it back to Workday where the new value will be set as the Workday Account and Miami UniqueID "Other ID" value.

Any subsequent changes to a UniqueID must be made via the identity system. The identity system will push the new UniqueID value to Workday, updating both the Workday Account and "Other ID" value.

Steps will be taken to limit who has the ability to change Workday Account and Miami UniqueID values in Workday.

 

Other IDs

Most additional IDs come from external systems and as a general rule should not be changed in Workday. Typically an integration of some sort will be responsible for updating IDs.