Topics Map > Business Systems > Manifest
Manifest - Data Driven Groups
Manifest provides applications the ability us use institutional data for grouping.
A note on group visibility
There are a lot of data driven groups. Not all of them will be visible to you, both for performance and security reasons. If you are not seeing a group you think you should see, please contact us to ask for help.
There are performance implications for users with access to see a large number of groups, both in the ability to search, and the ability to select the group you are looking for from the list of groups that all have quite similar names. For this reason, some less-commonly accessed groups are hidden from the default public view. Contacting Manifest Support to ask for help will get you access.
Other groups are hidden for privacy and security 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.
UDDS is used on campus to organize employees and employee-like populations. It is important to realize that both Job records (employees) and POI records from HR (non-employee, eg consultant or others) have UDDS assigned to them that can be used for grouping. Legacy Spec Auth entries also have "Organization UDDS" attached to them, but they are not usable for grouping.
- Note that there is data for other campuses. Because of historical relationships with other campuses with staff in Madison, there is some Job and POI data from other campuses. If you mean only to get people from UW-Madison, be sure to navigate to the 'A' folder in the UDDS trees.
- Job-based UDDS groups can be found under
uw:ref:hr_system:job(click the "Folders" tab if you don't see the folders listed). There are current as well as future job data, broken down from division to individual groups in a tree.
- Within the job-based UDDS tree there are folders for organization by title code and job type to facilitate selecting populations by those factors.
- Unfortunately there is not easily accessible or reliable translation from title code and job type to names. We hope to remedy this for the human-readable names in the future.
- POI-based UDDS groups can be found under
uw:ref:hr_system:POI(click the "Folders" tab if you don't see the folders listed). POI has no concept of "future" or "past" so the only option available is "Current."
- For POI types the descriptions are easily accessible and less complicated than job data, so the display names for folders and groups are more descriptive.
Unfortunately descriptive information is not easily available, so you have to deal in UDDS codes, title codes, and job type codes. We hope to remedy this in the future, but for now, some examples:
- To navigate the UDDS tree, for example:
- For all current UW-Madison employees:
- For all current employees in a division add the 2 digit identifier:
- For a department add the next two digit identifier onto that:
- For a subdepartment (a/k/a "group") add the final two digits:
- For all people with a job type of "Faculty" (FA) in UW-Madison,
uw:ref:hr_system:job:current:udds:A:types:all_A-FA. For a list of job types (A/K/A Empl Class), see HRS Documentation.
- For all people with a title of "Professor" (C20NN) at UW-Madison:
uw:ref:hr_system:job:current:udds:A:titles:all_A-C20NN. For more information on titles, see OHR Documentation.
NOTE: 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 UDDS group after they are gone. If you are using groups for detailed access control, you may need to take this in to 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.
- "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.)
- 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)
- Each College
- Individual Programs
- Individual Plans
- 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):
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:
Level of Assurance Groups
Level of Assurance groups allows for application owners to limit access to users based on their level of identity proofing. See "Application of NIST 800-63 to UW-Madison" on: https://www.cio.wisc.edu/security-initiatives-levels.aspx for the official source on level of access(Please note Level 0 is now part of Level 1). Manifest merely provides the groups for applications to consume, it does not define them.
The above link is the definitive source on Level of Assurance, but the following is general information:
- 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:
[LOA] can be replaced with "loa_1", or "loa_2"