Intended Audience and Contact Information
| Contact | Chief Data Officer, Office of the CIO |
|---|---|
| Intended Audience | Internal UBC |
| UDM Domain | Person |
| Data Standard ID | DG0066 |
Purpose
This standard aims to achieve consistency around the data collected for Person Affiliation Type, and the format in which it is collected and stored.
Person Affiliation Type is the relation of a person being associated with UBC.
This standard is derived by UBC and applies to all applications collecting Person Affiliation Type. Exceptions are listed in the Dispensation section.
Standard-Under Review
The following are the accepted values associated with a Person Affiliation Type:
| Accepted Value | Definition |
|---|---|
| Alumnus/a | An individual who completed a UBC senate approved program and was admitted into convocation or was granted alumnus status by the UBC Alumni Association. |
| Donor (Advancement) | An individual or organization that is a reported donor, or receives spousal recognition credit. |
| Donor (Contact) | An individual identified as a contact for a donation. |
| Volunteer | An individual that provides their time, service, and/or expertise without remuneration of any kind. |
| Applicant for Admissions | An individual who has completed at least one Admission Application form, and the corresponding application fee has been paid or a fee waiver has been redeemed. |
| Applicant for Employment | A person who has applied for employment with the University. |
| Guest | A person who is or has attended a UBC event and is not one of the other affiliation types. |
| Member | A generic affiliation type is associated with all UBC affiliates independently of the current affiliation type of the individual. |
| Learner | See Learner. |
| Worker | See Worker. |
| Pensioner | A person enrolled in UBC's faculty or staff pension plans. |
Compliance
The above standard must be complied at every stage of the data lifecycle with the exception of any dispensations (see Dispensation section):
- All applications must collect date 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. As systems are replaced, adoption of this standard is required. Examples of legacy systems are:
- Student Information System (SIS)
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 dispensation temporarily, please contact the Enterprise Data Governance Team.