Report Metadata Standard

Intended Audience and Contact Information

Contact	Chief Data Officer, Office of the CIO
Intended audience:	Internal UBC
UDM Domain:	Reporting

Purpose

The purpose of this standard is to achieve consistency in the development of enterprise tactical, operational and regulatory reports, regardless of the reporting tool used to develop the report.

For reports developed in Workday, see the Workday Report Standard.

This standard is to be adhered to at all times. Exceptions are listed in the Dispensation section.

Standard

Each enterprise report and its associated metadata must be tracked in the Report Catalogue.

A report is a well-structured data output that informs an audience on a particular topic, and can be used to support business processes, analysis and decision making.

A UBC Standard report should only be created when there is a justified purpose, a defined business owner, and no other report that currently exists meets the end-user's requirements. This can be done by verifying against the Report Catalogue.

New Report Metadata

All reports that meet the above criteria are required to be registered with the metadata in the following table. More details on each metadata element are provided in the subsequent section.

Metadata	Description	Format	Requirement
Basics
Report Name	The title used to refer to the report.	Refer to Report Name section	Required
Purpose	The business need or objective for the report.	Text	Required
Description	Detailed explanation for the report including key highlights, navigation, etc.	Text	Optional
Intended Audience
Category	The intended utilization of the report.	Reference List: (multiple selection by priority) Operational / Tactical Regulatory Strategic / Management Audit	Required
Intended Audience Unit	The unit(s) for which the report is intended for.	For Internal: Functional Unit List	Required
Intended Audience Unit	The unit(s) for which the report is intended for.	For External Organization, refer to the External Organization Name Data Standard.	Required
Data Domain	The common overarching data community the data is being reported on.	Reference List: UBC Shared Data Human Resources Learner Finance Advancement Teaching and Learning Services Geospatial Research	Required
Business Functional Area	The primary functional area within the Data Domain the data is being reported on.	Reference List	Required
Roles & Responsibilities
Business Owner	The person that approves: access requests to the report if required, change requests to an existing report, and deprecation of reports that are no longer in use.	Full Name: < > Role: < > Email: < > Functional Org. Unit:<>	Required
Data Steward	The person responsible for the guaranteeing the reliability for the information provided as well as execution of operational tasks (monitoring, auditing or performing changes).	Full Name: < > Role: < > Email: < > Functional Org. Unit:<>	Required
Technical Contact	The team that develops and maintains the report based on the direction of the Report Business Owner.	Reporting Team/ Assignment Group (if available in ServiceNow)	Required
Report Signed Off By	The individual that is appointed by the Report Business Owner that acknowledges that the report meets the initial gathered requirements.	Full Name: < > Role: < > Email: < > Functional Org. Unit:<>	Required
Technology
System of Record	An authoritative system where data is created/captured and/or maintained through a defined set of rules and expectations. To ensure data integrity, there must be one system of record for a given data element or piece of information.	Application Name (ApplicationAcronym)	Required
System of Reference	An authoritative system where data consumer can obtain reliable data to support transactions and analysis, even if the information did not originate in the system of reference.	Application Name (ApplicationAcronym)	Optional
Reporting system	The system where the report is created.	Application Name (ApplicationAcronym)	Optional
Reporting Tool	The tool used to build the report.	Application Name (ApplicationAcronym)	Optional
Publish Location	The link to the location of the report.	URL, Network Drive Location, etc.	Required
Delivery Format	The style or structure in which the report is presented.	Tabular, Visaulization, PDF, Excel, etc.	Optional
Report ID	The report identifier in the reporting tool.	Alphanumeric	Required if available
Data
Data Source Table Name(s)	The name(s) of the table in the Reporting System where the report fields are gathered from.	ApplicationName_TableName	Optional
Data source Field Names	The name(s) of the fields in the data source table. This includes identification of Calculated Fields and the respective calculations used.	FIELD_NAME(s) or Link to Physical Data Dictionary e.g. First_Name	Optional
Report Attributes	The link to the University Glossary for each field used in the report, including business terms, calculated fields, KPIs, etc.	University Glossary URL e.g. Given_Name	Optional
Contains Personal Information	Indicates if identifiable Personal Information is included in report.	Reference List: Yes No	Required
Level of Detail	The granularity or extent of the information included in the report in the lowest available drill-down. Case-level data divulges individual information for each represented data element e.g. student numbers, employee ID, etc. Anonymized data is case-level data that is irrevocably stripped of identifiers and a code is not kept to allow for future re-linkage. Aggregated data are data that are combined from several measurements making the risk of identification of individuals low.	Reference List: Case-level Anonymized Aggregated	Required
Parameters	Values defined by the system or by the user to be used in a query condition during report runtime controlling the contents and presentation of a report.	Text	Optional
Refresh Frequency	Rate at which a report is refreshed over a particular period of time.	Reference List: Real-time / On demand Daily Weekly Monthly Quarterly Every Term Every Session Annually (Gregorian) Annually (Fiscal) Annually (Academic) Other	Required
Publish Date	The first date the report is published for use.	Date	Required
Report Key Words / Tags	Enable discovery of reports to users when used in a search.	Text	Optional
Consumption Tracking Available	Indicates whether the report is being used.	Reference List: Yes No	Optional
EDG Certified	Indicates that the report has been authorized for publication.	True/False	Required
Report Catalogue ID	An identifier generated upon the registration of the report in the University Report Catalogue.	Auto-generated	Required

Metadata on a Published Report

At a minimum, the following metadata are to be visible on any published report:

Metadata	Description	Format	Requirement
Report Name	The title used to refer to the report.	Refer to Report Name section	Required
Purpose	The business need or objective for the report.	Text	Required
Description	Detailed explanation for the report including key highlights, navigation, etc.	Text	Optional
As-of Date a.k.a. Snapshot Date	The date the data in the report refers to.	Date	Required
Refresh Date a.k.a. Last Update Date	The last date the report was refreshed.	Date	Required
Report Run Date a.k.a. Last Update Date	The date the report is run by the user.	Date	Required

Modified Report Metadata

The following are metadata required when modifying a registered report:

Metadata	Description	Format	Requirement
Modified On	The latest date a report definition is modified after being published	Date	Required
Modified by	The latest person that modified the report	Full Name: < > Role: < > Email: < > Functional Org. Unit:<>	Required
Modification Signed Off By	The individual that is appointed by the Report Business Owner that signs off the modifications of the report definition	Full Name: < > Role: < > Email: < > Functional Org. Unit:<>	Required
Modification Details	The details of what changes were made to the report definition.	Text	Required

Report Name Standard

The following general guidelines are to be used when for naming custom reports:

Item	Guideline
Terminology	Ensure terminology used is in alignment with the University Glossary and University Data Model. If terminology is not available in the University Glossary, submit a Data Governance Request with all the appropriate details to have it added.
Title case	Use title case i.e., use capital letters for the principal words; do not capitalize prepositions, articles, or conjunctions.
Length	As much as possible, keep the length of the report name limited to allow it to be fully visible on the end user's screen.
Abbreviations	Avoid using abbreviations unless it is institutionally common practice to abbreviate a word or phrase. Longer, more detailed names can be very useful in communicating the purpose of a report to a user. Faculty Fac
Avoid using '&'	Spell out the word 'and' instead of using an ampersand (&).
Be clear and specific	The report name should clearly state the purpose of the report. Use a descriptive name to give the user an idea about what the report provides.
Use of Hyphens (-)	Use spaces instead of hyphens or underscores between words as it can affect the user's ability to search for a report, except: To set off part of the name: If you need to use a hyphen to set off part of the name from the rest, surround the hyphen with spaces. Example: Benefits Premium Report - Health Care When the hyphen is part of a word, abbreviation, or form name and you expect users to include the hyphen in searches. Example: Year End Financial Statements - Long-term Debt.
Reports that Contain PI¹or sensitive information	Include the PI or sensitive information element in the report name to enable users to be more careful while handling or sharing the report.

¹ For more information about PI, visit Privacy Matters @ UBC.

Column Name Standard

To name a column, or utilize a Column Heading Override, use the following standard:

Column names will have only A-Z, 0-9, underscore (_) and hyphen (-) characters.
Use title case i.e. use capital letters for the first alphabet in the principal words.
Column names must be consistent with the field or attribute it represents.
Column names should not be cryptic and should be intuitive. Ideally should use long names instead of short meaningless abbreviations.
The following is the standard naming convention for a column:

[PRIME WORD] [MODIFIER/QUALIFIER words or phrases] [CLASS WORD]

Where

PRIME WORD: Provides the context to where that column is from. Usually can be mapped to the master or transaction entity associated to the column
MODIFIER/QUALIFIER: Specifies the specific information within the Prime word
CLASS: Defines the category of the data in that column

The PRIME_WORD component is optional in case it is self-evident within the context of the report.

For example: Account Activation Status Code

Account - Prime Word
Activation Status - Modifier/Qualifier word or phrase
Code - Class Word

In the example above, if the report is all about Account information, then the column name could omit Account and be only Activation Status Code

It is important to choose a qualifier that is not ambiguous or too generic. Account Status Code can be very vague, whereas Account Activation Status Code will inform much more precisely the purpose of that column.

A list of standard Classes includes:

ADDRESS
ADDRESSLINE
AMOUNT (A numeric value of money)
CODE
COUNT
CROSS REFERNECE
DATE
DAY
YEAR
MONTH
DESCRIPTION
FLAG
IDENTIFIER
INDICATOR
KEY
LOCATION
NAME
NUMBER
SERVICE
SEX
STATUS
TEXT
UNIT

Access to Reports

Access to a report that is outside of the intended audience requires the submission of a Data Access Request form which will be reviewed and approved by the appropriate Report Business Owner.

Visit Access UBC Data for more information on the data access request process and to access the required form that needs to be completed.

Change Requests to Reports

Any changes to reports require Report Business Owner consultation and approval. To request a change, reach out to the Report Business Owner specified for the report.

If you wish to report a data quality issue related to a report, reach out to the Data Steward indicated.

Deprecating a Registered Report

Deprecating reports requires Report Business Owner consultation and approval.

Temporary reports must be marked with a prefix 'DNU'. Any reports with 'DNU' will eventually get deleted after review.
Reports not used for more than 25 months should be automatically be candidates for deprecation, following the consultation approval process.
Consult with users and give them time to respond before deleting reports that are not being used.

To request deprecation of a report, reach out to the Data Governance team. They will liaise with the Report Business Owner and update the Report Registry accordingly.

Security of Reports

Both Report Business Owners, and Administrators should be vigilant about who has access to their reports. On a periodic basis, an audit report should be generated to be distributed to each unit, with a list of the employees in that unit who have access to their reports, as well as identify the level of access for each.

The Report Business Owner is required to carefully review, update, or terminate access as appropriate based on an employee's current job duties.

Units are required to update or terminate access for any employees who change jobs or leave the University as soon as the change occurs.

Compliance

This standard must be complied through every stage of report development and maintenance with the exception of any dispensations (see Dispensation section)

Dispensation