FAQs

A Data Standard provides detailed rules on how data is described and recorded within an enterprise business application. Typically, a Data Standard is documented for a data element that has been modelled in the University Data Model (UDM), defined in the University Glossary, and falls under a defined data domain such as Person, Human Resources, Learner, Academic, Finance, Asset, Hazard, Organization or Location.

Data Standards can take different forms depending on what they describe. They can assert how a field must be populated, rules governing the relationships between fields, detailed documentation of acceptable and unacceptable values, format, etc.

View the Data Standards.

Data Standards are developed by the Enterprise Data Governance team in consultation with identified stakeholders, often within a working group, and approved for publication by a Data Trustee or a Governing Body, such as the Data Governance Steering Council.

Enterprise Data Standards must be followed when a business application is integrated with central systems, to ensure uniformity and interoperability of the shared data.

When implementing a data element in a business application, implementers should reference the list of Data Standards to determine if a standard has been defined, and is applicable. If you cannot find a Data Standard for a data element that you wish to implement, reach out to the Data Governance team to determine if one is required.

Compliance with Data Standards ensures our data has integrity, is trustworthy, and is of a benchmarked quality, in support of our business processes, decision making, and reporting.

Where a data element or attribute is deemed ‘required’, it must be implemented as ‘required’ in a business application. For example: if a business application decides to collects a person’s name, the Person Name Data Standard specifies that they are required to collect Legal Name type; Preferred and Alternate Name types are optional to collect.

Where a data element or attribute is deemed ‘optional’, it may be implemented as required or optional depending on underlying business needs. For example: per the example above, if Preferred Name type needs to be collected as a required data element, they may do so.

It is highly recommended to comply with approved terminology as stated in the Data Standard and the University Glossary. Naming a data field using different terminology than what is outlined in a Data Standard (that might have a different definition) may cause confusion, make the data less reliable, and have ramifications for reporting.

For example: if a business application decides to collect “Gender” with the prescribed set of accepted values per the Sex and Gender Data Standard – Man, Non-binary, Woman, Choose not to disclose - the label for the attribute in the business application must be “Gender” and not “Sex”.

It is highly recommended to comply with approved representation of reference data values as prescribed in the Data Standard, including any capitalization. Business application integration processes will only recognize the exact allowed values, especially when a crosswalk translation mapping is required. For example: an accepted value for Gender - “Non-binary” - should be represented as “Non-binary” and not “Non binary” or “Non-binary person” or “non-binary person”.