Manifest provides applications the ability us use institutional data for grouping.
There are a lot of data driven groups. Not all of them will be visible to you, both for performance and privacy (eg, FERPA) 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.
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 identity your population using data, please contact Manifest Support for help.
Department ID from HRS (commonly called 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.
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.
titles) and job type (
types) to facilitate selecting populations by those factors.
pay_basis) and Job Location (
locations), these are not populated through all UDDS for performance reasons please contact us if you need more.
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."
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:
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.
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-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.
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:
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 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:
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"