Intended Audience and Contact Information
| Contact | Chief Data Officer, Office of the CIO |
|---|---|
| Intended audience | Internal UBC |
| UDM Domain | Multiple Domain |
| Data Standard ID | DG0060 |
Purpose
This standard aims to achieve consistency for naming Workday Security Groups and assignable roles by prescribing a naming convention and the attributes to be collected and recorded.
This standard applies to role-based, user-based security groups, assignable roles and shell roles in Workday.
Role-based security group is a collection of permissions defined for a system that is related to an Assignable Role.
User-based security group is a collection of permissions defined for a system that can be assigned to a specific user.
Assignable role is a mechanism for the collection of role assignments (membership). Assignable Roles are assigned to Positions. Workers hired into a position inherit the role assignment through the position.
A shell role is a UBC construct and is an assignable role without relation to a security group. The shell role functions only derive the workers (membership) hired into the applicable positions. Through the UBC integration, the workers (membership) are loaded into the third-party system (e.g. Appian, Award Cloud, ADM) where the collection of permissions is determined.
Security Groups Standard
Workday Security Groups must be tracked and reportable. This can be better achieved by following a consistent naming convention, and recording attributes of the Security Group. A new Workday Security Group should only be created when there is a justified purpose, a defined security business owner, and no other Security Group or security role that currently exists meets the end-user's requirements. This can be done by verifying against the inventory in Workday.
A Security Group name is comprised of standardized name elements that incorporate meaningful metadata for UBC in Workday.
The following are the naming conventions for role-based and user-based Security Groups and the additional fields (attributes) to be completed when creating a new Workday Security Group.
Naming Convention
The naming convention for role-based security group is comprised of two parts:
<Assignable Role1> <(Access Rights to Organization)2>
1See Assignable Role section for details on how this component is in Workday HCM/Finance/Payroll vs Workday Student.
2See Access Rights to Organization Section for details on this component.
Example of a Role-based Security Group Name:
Assignable Role
The Assignable Role name component is comprised of different elements for Workday Student vs. Workday HCM/FINANCE/PAYROLL (HCM/FIN/PAY).
For Workday Student, the assignable role name component is comprised of three name elements:
<Primary Functional Area> <Descriptive Role Name><(Role Usages)>
Each name element has a controlled list of acceptable values to select from, as per below:
| Primary Functional Area Accepted Value | Descriptive Role Name Accepted Value* | Role Usages Accepted Value |
|---|---|---|
| Academic Advising | Staff | (Academic Unit) |
| Academic Foundation | Leadership | (Student Cohort) |
| Action Items and Holds | Specialist | (Academic Record) |
| Admissions | Administrator | (Student Cohort Collection) |
| Campus Engagement | Coordinator | (Program of Study) |
| Financial Aid | Advisor | (Course Section) |
| Student Core | Instructor | |
| Student Financials | ||
| Student Records | ||
| Student Recruiting |
*Note: As an exception, the <Descriptive Role Name> element may require a sub-category qualifier due to business needs. This can be added to the <Descriptive Role Name> element.
e.g. Student Financials Refund Specialist (Student Cohort Collection), Student Financials Customer Invoice Specialist (Student Cohort), etc.
Definitions for all values included on the "Descriptive Role Name" list can be found under the University Glossary.
A few examples of Assignable Roles:
| Assignable Role name |
|---|
| Academic Advising Leadership (Academic Unit) |
| Student Core Specialist (Student Cohort) |
| Student Financials Refund Specialist (Student Cohort Collection) |
For Workday HCM/FIN/PAY, the assignable role name component is comprised of two-name elements:
<Descriptive Role Name>< (Role Usage)>
e.g. Academic Executive (Faculty Member)
The Descriptive Role Name element should be a unique and complete name that is descriptive enough to provide others with an understanding of the subject and purpose for the role.
The Role Usage element is selected from the following controlled list of accepted values:
- Award Contract
- Candidate Pool
- Committee Definition
- Company
- Company Hierarchy*
- Cost Center
- Cost Center Hierarchy*
- Course Section
- Customer
- Faculty Members
- Function Hierarchy*
- Functional Unit Hierarchy*
- Fund
- Fund Hierarchy*
- Gift
- Gift Hierarchy*
- Gift Initiative
- Gift Initiative Hierarchy*
- Grant
- Grant Hierarchy*
- Internal Service Provider
- Job Requisition
- Location
- Location Hierarchy*
- Matrix
- Pay Group
- Program
- Program Hierarchy*
- Project
- Project Hierarchy*
- Prospect
- Recruiting Agency
- Region
- Region Hierarchy*
- Resource Pool
- Resource Pool Hierarchy*
- Retiree
- Service Center
- Student Cohort
- Succession Pool
- Supervisory
- Talent Pool
- Union
- Work Learn
*If the Role Usage contains the word "Hierarchy", the assignable role name should replace it with a plus sign ("+") for brevity. Please see example below:
Access Rights to Organization
The second part of the Role-based Security Group naming convention is Access Rights to Organization name element, which applies to both Workday Student and HCM/FIN. The following are the accepted values for Access Rights to Organization:
| Accepted Value Code | Accepted Value Name | Description |
|---|---|---|
| (Unconstrained) | Unconstrained | Applies to all unconstrained role-based groups |
| (CO) | Current Organization | Applies to current organization only |
| (COUS) | Unassigned Subordinates | Applies to current Organization and Unassigned Subordinate |
| (COAS) | All Subordinates s Rights to Organization Code | Applies to current organization and all subordinates |
| (COASAP) | All Positions | Applies to current organization and all subordinates for all positions |
Attributes of Role-Based Security Groups
When creating a new Security Group, in addition to its name, you must also enter information about the group in the Comment Field and the Context Type Field. The following provides additional details on how to collect and record this information.
Comment Field
Enter a short description that includes the permissions associated with that group and the purpose for that role.
Example of Comment:
Context Type Field
All role-based security group has the context type setup as one of the two options:
| Constrained by Role Access |
Indicates when a user has contextual access to a subset of data when accessing an item. Target constraints in Workday are typically based on organization, but can also be determined by level or segment. Example: A Manager, can only see Performance data for workers in the supervisory organization to which they are assigned. Alternately, an Employee (self-service security group) can only see their own home address, and not the home address of any other worker. |
|---|---|
| Unconstrained |
Indicates when a user has access to all target instances when accessing an item. Example: A Compensation Administrator can see compensation for all workers in the system. |
Example of Context Type:
Naming Convention
The User-Based Security Groups should be used as an exception to Role-based Security Group and assigned to administrators, auditors, report writers.
The naming convention for user-based security group is comprised of two elements as follows:
<Product Area1,2><Descriptive Name3>
1Product Area: Describes a specific Workday area that is assigned to domain.
2 See exceptions below.
3 Descriptive Name: Includes a short description that is descriptive enough to provide others with the area that is for and the purpose for the role.
Below are accepted values for Product Area:
| Product Area Accepted Value Code | Product Area Accepted Value Name | Product Area Description | Examples |
|---|---|---|---|
| STU | Student | The group name is specific to the Workday domain of students | STU Auditor STU Academic Foundation Administrator STU Academic Advising Administrator STU Administrator STU Admissions Administrator STU Financials Administrator STU Calculations Administrator STU Core Administrator STU Financial Aid Administrator STU Records Administrator |
| HR | Human Resources | The group name is specific to the Workday domain of human resources | HR Administrator HR Organization Administrator HR Planning Administrator HR Auditor |
| FIN | Finance | The group name is specific to the Workday domain of finance | FIN Data Maintenance FIN Administrator FIN Auditor FIN Organization Administrator |
| PAY | Payroll | The group name is specific to the Workday domain of payroll | PAY Administrator PAY Administrator USA PAY Auditor PAY Calculations Administrator |
| ISC | Integrated Service Centre | The group name is specific to ISC team | ISC Configuration Analyst ISC Migrators ISC Product Payroll View ISC Product Finance View ISC Product System View |
3Some exceptions exist where the user-based security group does not have a product area attached to their name and the naming convention includes only <Descriptive name>. Examples include:
- Report Writer
- System Auditor
- Business Process Administrator
- Security Administrator
- Security Configurator
- Service Centre Administrator
- Setup Administrator
- UDaP Support
Example of User-based Security Group name:
Attributes of User-Based Security Groups
Comment Field
Enter a short description that includes the permissions associated with that group and the purpose for that role.
Context Type Field
All user-based security groups are setup as "Unconstrained" permissions.
Shell Roles in Workday are intended to allow the assignment and de-assignment of rights to workers by position in 'downstream' applications such as Learner Financial Support and several applications that will use the Appian (BPMS: Business Process Management System) platform for authentication and authorization. These roles have no permission rights in Workday, propagating required credential data 'downstream' through Common Services APIs.
The naming convention for Shell Role-Based is comprised as follows:
<X:Target System(Application*)1:Role Description>
1*(Application) name will only apply for Business Process Management Systems.
Example of a Shell Role for business processes management systems:
<X:BPMS(SUCD):ITDV>
Example of a Shell Role for non- business processes management systems (e.g. LFSM, ADM, OAM):
<X:LFSM:FINAIDADMIN>
| Accepted Value Code | Accepted Value Name | Description |
|---|---|---|
| X | Shell Role | It is an assignable role without relation to a security group, no permissions are setup in Workday. |
| Letter code per IRP Student Ecosystem Application Inventory | Target system | The system where the Shell roles need to be authorized against. Example: BPMS, ADM, LFSM, etc. |
| Letter code per IRP Student Ecosystem Application Inventory | (Application) | The application within the target system and is included in the shell role name only if it is for BPMS. Example: (SUCD) for UBC Carding within BPMS target system. |
| Letter code associated with Role description | Role Description | The plain text description of the business function assigned to the role. Example: ITDV for IT Developers, FINAIDADMIN for Student Financial Aid Administrator |
Access to Workday Security Groups
Access to Workday Security Groups will be reviewed and approved by the appropriate Security Role Owner.
Security Role Owner: is an individual who has accountability for a group of the Workday roles and security groups that correspond to their function. It is recommended that the responsibilities be incorporated into the activities of a subset of Data Stewards. For example, the Director, Financial Reporting & Budgeting is accountable for all institutional accounting roles.
The Role Owner is tasked with the following responsibility for the roles and groups under their purview:
- The maintenance and assignment of security groups
- Approving the Assignment of Role-Based Security Groups to Positions or users
- Second level approval as part of re-certifying users
- Approving the development and user acceptance of security group changes
Visit Security Role Request Process for more information on the access request process and to access the required form that needs to be completed.
Change request to Workday Security Groups
Any changes to security group access require Role Owner consultation and approval. To request a change, reach out to the Role Owner who has accountability for a group of the Workday roles and security groups that correspond to your function.
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 data 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.
For any compliance questions or requests for a dispensation temporarily, please contact the Enterprise Data Governance Team.
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.