Manifest - Data Driven Groups
Quick Jump to: Workday Groups - Student and Applicant Data - Level of Assurance
This document documents data-generated groups based on data from source systems There are also specific interesting "Reference" groups documented: [Link for document 102219 is unavailable at this time].
A note on group visibility
There are a lot of data driven groups. Not all of them will be visible to you, primarily for privacy (eg, FERPA) reasons. For example, groups containing FERPA protected students or other protected groups are not visible without proper authorization. Gaining access to these groups for UW business purposes is simply a matter of filing an Identity Data Integration (IDI) request to record who has access. As always, if you have questions or aren't sure, please contact Manifest Support to ask for help.
If you don't see a group listed here or if you are interested in grouping based on data that we don't have (or you think we don't have) please contact us to ask. We are always interested in loading new data and creating new useful structures if we can.
A note on group membership visibility
As a general rule, you cannot view the membership of data-driven groups. This is both for privacy as well as practical technical reasons (the way the groups are constructed does not lend itself to this sort of view). The groups are based on institutional data and are kept in sync with institutional sources at least daily. If you need help understanding the population in a data-driven group or are converting and need help to identify your population using data, please contact Manifest Support (manifest@doit.wisc.edu) for help.
Workday (HR) Groups
Supervisory Organizations, Cost Center Hierarchies, and Cost Centers are all used on campus to organize employees and employee-like populations. It is important to realize that both Job records (employees) and Contingent Worker records from Workday (non-employee, e.g. consultant or others) have organizational groupings assigned to them that can be used for grouping purposes.
For example, an employee or contingent worker in IAM would be associated with the following organizational groupings:
-
SO00002796|IAM Identity Services
-
CC003040|UWMSN | DoIT | Application Infrastructure Services
-
CCH000447|UWMSN | CCHL7 | DoIT | Application Infrastructure Services
Workday-based groups are available for grouping purposes without further data authorization. You should be able to add them directly by name or ID paths listed below.
Important Notes:
-
Groups only exist when someone is in them. Because of the way HR is integrated, we don't know a SupOrg/CC/CCH, title, or type exists until a person appears in or has it. If you don't find a group you are looking for, this is likely why. If you think you have found an error, or you are in a hardship (preparing for an orderly transition to a new UDDS, for example), please contact us to ask for help and advice.
-
"Direct Employees" and “Direct Contingent Workers” groups contain only the people with jobs or contingent positions in that Org, they do not include employees that are members of downstream organizations. For example "Direct Employees" of O00000027|Office of the Chancellor would only contain employees of the Office of the Chancellor, not any employees downstream groups supervised by the Office of the Chancellor (like DoIT).
-
“Direct + Indirect Employees” and “Direct + Indirect Contingent Workers” groups contain all of the people within that org, in addition to all of the members of downstream organizations.
For example "Direct Employees" of SO00000027|Office of the Chancellor would contain both employees of the Office of the Chancellor and any employees of downstream groups supervised by the Office of the Chancellor (like DoIT). -
These groups do not exclude Student Help or Student Assistants. If you would like assistance with creating a composite group that subtracts student help from a given population, please contact us to ask for help and advice.
Usage notes:
-
Job-based Workday groups can be found under:
uw:ref:workday:sup_org:current for Sup Org groups (typically SupOrgs are our recommended grouping option for most fine-grained grouping capabilities).
uw:ref:workday:uw_org:current for Cost Center and Cost Center Hierarchy groups (these groups can be more useful for Department/Division wide grouping capabilities).
Click the “Folders” tab to see all of the available organizations. You can click the filter icon to sort through the organization folders to find the org you’d like to use. More detailed instructions on how to do this can be found here:Manifest - Adding Workday Data Driven Groups to Your Groups
Step 1: Identify the Manifest group you’d like to add the data driven groups to.
Identify the Manifest group you’d like to add the Workday data-driven groups to. Either pick a pre-existing manifest group you manage, or create a new manifest group.
Step 2: Find the Workday Organization Manifest Group you would like to use.
-
To find a Supervisory Organization Group in Manifest, go to the uw:ref:workday:sup_org:current folder in Manifest.
-
To find a Cost Center group or Cost Center Hierarchy (CCH) via UW Organization Structure (UWOS) group, go to uw:ref:workday:uw_org:current folder in Manifest.
-
Do not navigate to Workday groups through the “Browse” box to the left. You will run into performance issues because the tree structure for Workday groups is very large.
-
-
Click the “Folders” tab.
- Click the Filter Icon (
) and modify the filter with relevant details such as the Supervisory Organization number or organization name, then click the blue Filter button.
- Click the Open button on the Workday Organization folder you’d like to open.
- Click the “Groups” tab to see the groups associated with that Workday Organization.
- Each Workday Organization folder will contain four different groups. Here is a breakdown of each of the groups and what they mean:
-
-
Direct employees: Employees who are directly affiliated with an organization by their position. This includes populations such as paid, active, and future employees.
-
Direct + indirect employees: Includes all direct employees affiliated with an organization by position as well as indirect employees. Indirect employees are those that belong to a “parent” organization because they are a member of a “child” organization. For example, within DoIT, the Identity & Access Management (IAM) department is organizationally under Application Infrastructure Services (AIS). Direct Employees of IAM (child organization) will be Indirect Employees of AIS (parent organization).
-
Direct contingent workers: Includes contractors, emeritus, volunteers, and others who are directly affiliated with an organization.
- Direct + indirect contingent workers: Includes all direct contingent workers affiliated with an organization as well as indirect contingent workers. Indirect contingent workers are those that belong to a “parent” organization because they are a member of a “child” organization.
-
-
- Each Workday Organization folder will contain four different groups. Here is a breakdown of each of the groups and what they mean:
- Click the "Details" button for the group you want to use.
- Copy the path of the group.
Step 3: Add the Workday Organization to your Manifest group
-
Navigate to your Manifest group that needs to have the Workday Organization added
-
Click the “Members” tab. Click the “+ Add member(s)” button.
-
In the “Add group member” field, paste the group path you copied in "Step 2: Find the Workday Organization Manifest Group you would like to use."
-
Manifest will query for the group as you type. Click the desired Workday Organization group when it pops up below the search field.
-
- The Workday Organization group will now be listed in the “Members to Add” field. Click “Save”.
Add Individuals to Your Manifest Group
A Manifest group can contain groups and individual members/people. If you need to add people individually to your Manifest group please use these directions: Manifest - Manage Group Members.
-
-
There are also top-level Job Type and Job Title groups that allow you to add all individuals at UW-Madison with a given Job attribute. They can be found under:
uw:ref:workday:job_type:current for job type groupings such as all Academic Staff or all University Staff.
uw:ref:workday:job_title:current for job type groupings such as all AD001-Administrative Assistant I's or CW002-Consultant's
POSSIBLE PITFALLS:
When people leave, their job doesn't always go away immediately. There are many factors, from processing delays (often overnight) to the person using vacation or accumulated leave, especially after retirement. Because of this they will still be in a Workday group after they are gone. If you are using groups for detailed access control, you may need to take this into account.
Student and Applicant Data Groups
Student and Applicant data-driven groups are hidden by default and require an Identity Data Integration (IDI) request to access because they contain people protected under FERPA. Access to them needs to be reviewed and tracked by Enrollment Management.
Important Notes
- Groups only exist when someone is in them. Because of the way SIS is integrated, we don't know a plan or term (technically even a college or career, should a new one appear) exists until a person appears in or has it. If you don't find a group you are looking for, this is likely why. If you think you have found an error, or you are in a hardship (preparing for a sudden change for example), please contact us to ask for help and advice.
- "Student" data are based both on term and timeframe. For example: a student who is between the start and end dates of an ENRL record is "currently enrolled" but that enrolled record (for various business reasons) may not be actually in the current term (the student may be finishing studies after the term has ended.) Conversely, a student who is withdrawn is concurrently enrolled and withdrawn in the term (but is only currently WDRW and is past ENRL.) Term is almost never what you want to use and is the source of many bugs. Be careful.
- Further, not all careers have the same term at the same time: for example, spring (XXX4) for Undergrad career ends mid-may with graduation and people who are continuing transition in to summer (XXX6) until late August when the next fall (XYY2) starts, while Medical School spring ends in late June followed by a two week summer and fall starts early July. There are even cases where students are in more than one term at the same time.
- Unfortunately, eligible records break these rules and are only eligible in the term to which they belong. Unless you are looking for specific term eligibility, you almost always want current and future eligible groups.
This can be very confusing and lead to unexpected results. Please do not hesitate to contact Manifest Support to ask for help.
Student-related groups are located under uw:ref:student_system:students
. The groups are organized by term and timeframe (see note above), and within a term or timeframe the structure:
- Individual Student Statuses (ELIG, ENRL, WDRW)
- All Plans
- Individual Plans
- Each Career (UGRD, GRAD, LAW, MEDS, PHAR, VMED, USPC)
- Colleges
- Each College
- Individual Programs
- Plans
- Individual Plans
- Colleges
- All Plans
At each level there are All X
groups that roll everything down the tree up to that level. For example, all current enrolled undergrads: uw:ref:student_system:students:CURRENT:ENRL:UGRD:all_UGRD
or all enrolled (undergrad or any other career): uw:ref:student_system:students:CURRENT:ENRL:all_ENRL
.
Information about Programs and Plans can be found in the KB. Unfortunately how the academic structure at UW-Madison works and how programs, plans, colleges and careers relate is complicated. If you need help understanding programs or plans that you are looking for, your department has staff who know far more about what they mean than we do.
Unfortunately, groups based on courses are not available yet. It is a common request and we are working to understand how best to structure them.
Applicant-related groups are located under uw:ref:student_system:applicants
. Just like student groups there are groups for both terms and timeframes (see the Important Notes above). Applicant statuses are simpler than student programs and plans and only have a career and a status, so the structure is much less nested, for example: uw:ref:student_system:applicants:career_status:current:UGRD:all_current_UGRD
or uw:ref:student_system:applicants:career_status:current:MEDS:APPL
.
Level of Assurance Groups
Level of Assurance groups allows for application owners to limit access to users based on their level of identity proofing. Please note that Manifest provides the groups for applications to consume, but it does not define what Level of Assurance means.
NST 800-63 is the definitive source on Level of Assurance but the following summarizes the definition of Level 1 and Level 2 groups that are provided as data-driven groups within Manifest:
- Level 1: No identity proofing. Spec Pop identies(NetIDs created in Manifest) fall in this category.
- Level 2: Idenities have some proofing done. HR System and Student System Identies fall in this category.
- There are times where people from Level 2 would move to Level 1. Such as when they have too many failed password attempts.
Manifest users can consume LoA groups by entering a group location with the following naming convention:
uw:ref:loa:[LOA]
[LOA] can be replaced with "loa_1", or "loa_2"
- uw:ref:loa:loa_1
- uw:ref:loa:loa_2