Intended Audience and Contact Information
| Contact | Chief Data Officer, Office of the CIO |
|---|---|
| Intended audience: | Internal UBC |
| UDM Domain | Location |
| Data Standard ID | DS0101 |
Definition
Location [Workday] is a representation of a place where University business activity occurs.
Purpose
This standard aims to achieve consistency around the data created for Locations in Workday and the format in which it is stored.
This standard is derived by UBC and applies to Workday Location data.
Standard
| Attribute | Definition | Format |
|---|---|---|
|
Location Group This attribute is referred to as Campus in Workday |
The highest level of location hierarchy. | See Campus and Other Location Groups Data Standard for accepted values. |
| Location Type | A categorization of Locations based on common characteristics or functions. | See Location Type section for accepted values. |
|
Location Name This attribute is referred to as Location in Workday |
A set of words by which a place is known or referred to. | See Location Name & Code section. |
|
Location Code This attribute is referred to as Location Identifier in Workday |
A unique code for a Location (business key). | See Location Name & Code section. |
| Location Status | Availability of a location being used within a system. | Active/Inactive Flag |
| Seating Capacity | Number of people a place can seat for locations in which learning events like classes, activities, and assessments take place. | Number |
|
Location Hierarchy This attribute is referred to as Superior / Subordinate Location; Location Hierarchy in Worday |
The ordered geographic structure of Location types. | See Location Hierarchy section. |
| Location Usage | A categorization of Locations based on its use for a purpose or activity. | See Location Usage section for accepted values. |
| Default Job Posting Location | Defines the location for a job opportunity at the Location Group level, but is independent of the Location Hierarchy. | See Default Job Posting Location Name Standard section. |
The following are the accepted values for Location type in Workday. Please see the Location Type and Hierarchy Data Standard for the comprehensive enterprise standard.
| Accepted Value | Definition |
|---|---|
|
Location Group This is referred to as Campus in Workday |
The highest level of location groupings. See <Campus and Other Location Groups Data Standard>. |
| Building* | Any structure, including a usually roofed and walled structure and any affixed mechanical devices, built for temporary or permanent use, and that is used or intended for supporting or sheltering any use or occupancy. See Campus Building Data Standard for more information. |
| Floor | A structural level in a Building or in a Building subdivision as defined in UBC's Building and Records Data Standards. See Campus Floor Data Standard for more information. |
| Room | An Enclosed or unenclosed space(s) or area(s) of a building designed to serve a specific purpose. See Campus Room Data Standard for more information. |
| Under Construction | A location with an active Building Permit that is required for construction or renovation |
Note: Regional Locations are loaded as buildings in WD
The following are the rules for Location Name and Location Code, and are represented in the naming convention in the below charts:
- Locations names and codes must be represented within their location hierarchy context.
- Use a pipe ( | ) as a major delimiter to separate between the location levels represented in the location name or code. Do not use spaces around the major delimiter for codes.
- Use of minor delimiters within a location type name must only be used if it is true to the data from the System of Record.
- Location Codes and Location Names must be unique.
- When more than 1 level is represented in a location name, use the location Group code, rather than the full value for brevity. E.g. Use UBCV rather than UBC Vancouver Campus
- When a Building is part of the Location name, it should also include the Building Code.
- The word ‘Room:’ should be added for that location type name.
The following is the naming convention by Location type:
| Location Type | Location Name Format |
|---|---|
|
Location Group This is referred to as Campus in Workday |
<LocationGroupName> e.g. UBC Okanagan Campus |
| Building* |
<LocationGroupCode> | <BuildingName> (<BuildingCode>) e.g. UBCV | Acadia House (ACAH) |
| Floor |
<LocationGroupCode> | <BuildingName> (<BuildingCode>) | <FloorName> e.g. UBCO | Arts Building (ARTS) | Floor: 1 |
| Room |
<LocationGroupCode> | <BuildingName> (<BuildingCode>) | <FloorName> | Room: <RoomCode> e.g. UBCV | Acadia House (ACAH) | Floor: 1 | Room: 2700 - 107 |
Note: Regional Locations are loaded as buildings in WD, and will use the same standard as such, replacing building name and building code with regional site name, and regional site code respectively.
The following is the coding convention by Location type:
| Location Type | Location Code Format |
|---|---|
|
Location Group This is referred to as Campus in Workday |
<LocationGroupCode> e.g. UBCV |
| Building |
<LocationGroupCode> | <BuildingCode> e.g. UBCV|ACAH |
| Floor |
<LocationGroupCode> | <BuildingCode> | <FloorCode> e.g. UBCO|ART|1 |
| Room |
<LocationGroupCode> | <BuildingCode> | <FloorCode> | <RoomCode> e.g. UBCV|ACAH|1|2700 - 107 |
The following is the ordered geographic structure of Location types used in Workday. Please see the Location Type and Hierarchy Data Standard for the enterprise standard.
| Levels | Level Instance Value |
|---|---|
| 01 | Location Group (Referred to as Campus in Workday) |
| 02 | Building |
| 03 | Floor |
| 04 | Room |
A Location can have multiple Location usages at any given time. The following are the accepted values for Location Usage in Workday:
| Accepted Value | Definition |
|---|---|
| Business Asset | The physical location where you store an asset or where it's in use. |
| Business Site | The physical location of a business. |
| Instructional | A location in which learning events like classes, activities, and assessments take place |
| Work space | Spaces within a business site or another work space. |
| Ship to | Shipping locations used to associate ship-to addresses with deliver-to locations. |
| Housing | A residential site for students. |
| Job Posting | A job-posting location where you don't have an existing business site. |
| Campus | The physical grounds and buildings of the University. |
The following is the naming convention for Default Job Posting Locations by Location Group Type:
| Location Group Type | Name Standard |
|---|---|
| Campus |
<Campus> - <City>, BC, Canada |
| Off-Campus |
Where the city of the Off-Campus Location is within the province of British Columbia, use: UBC Alternate Site - <City>, BC, Canada Where the city of the Off-Campus Location is within Canada, but outside of the province of British Columbia, use: UBC Alternate Site - Other Canadian Where the Off-Campus site is outside of Canada, use: UBC Alternate Site - International |
| Hospital | UBC Hospital Site - <City>, BC, Canada |
Compliance
This standard about Regional Locations must be complied with every stage of the data lifecycle with the exception of any dispensations (see Dispensation section):
- All applications must collect Regional Locations as recommended in this standard.
- Enterprise Data Integration must adopt this standard.
Reference Data Compliance for Data Integration
The use of accepted reference data values in this standard for data integration among applications must comply with the enterprise integration pattern of leveraging the reference data common service API (Application Programming Interface) published in UBC MuleSoft Exchange.
Any application that intends to access real-time, case-level reference data should have the application owner or manager complete and submit a Request API Access form.
MAPPING OF INVALID VALUES FROM SYSTEM(S) OF RECORD (SOR) TO COMMON SERVICES
A common service can only accommodate standard reference data enumerations that are available in the SoR as approved by the Data Governance Steering Committee or Data Trustee.
A reference data value that does not match any of the standard reference data value enumerations is considered ‘invalid’. Any records from a SoR containing an invalid reference data value for a given data element or attribute must be mapped as an ‘empty’ value in common service(s). Where a reference data value may potentially have the same meaning as a standard enumeration but named differently in the system of record can be corrected to match the appropriate standard enumeration. Please consult with the EDG team in such cases.
Additional Reference Data values in a SoR that are not part of the standard reference data enumerations are to be omitted in the common service.
Dispensation
Legacy systems are exempt from this data standard. Examples of legacy systems are:
- Student Information System (SIS)
As systems are replaced, adoption of this standard is required.
As existing systems change to adopt this standard, the Enterprise Data Governance team needs to be informed.
For any compliance questions or requests for a temporary dispensation, please contact the Enterprise Data Governance Team.