Manifest - Data Driven Groups

Manifest provides applications the ability us use institutional data for grouping. Examples of institutional groups include HRS-driven UDDS groups (like all employees under A0000), or Student-System driven student groups (all students with a certain major). This can be quite useful if you need to populate groups for your department, e.g. establishing an-auto populating group for who can access the department intranet or creating a mailing list.

Quick Jump to: UDDS Groups - Student and Applicant Data - Level of Assurance

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 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 Manifest 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.

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 identity your population using data, please contact Manifest Support for help.

HR UDDS Groups

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.

HR-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:

There is some data for other campuses. Because of historical relationships with other campuses with staff physically located 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.
Groups only exist when someone is in them. Because of the way HR is integrated, we don't know a UDDS, 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.
"All" groups contain All people with jobs or POI (depending on context), for example "All Current Jobs in A" contains student employees as well as all other job types, paid or unpaid.

Usage notes:

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 (titles) and job type (types) to facilitate selecting populations by those factors. Title codes are truncated to 5 characters per OHR because the 6th character reflects only benefits information, not title, for example a group for AD026 contains people with titles AD026, AD026A, AD026U, and AD026X.
- Within the job-based UDDS tree there are folders for Pay Basis (pay_basis) and Job Location (locations), these are not populated through all UDDS for performance reasons please contact us if you need more.
- 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, pay basis, 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: uw:ref:hr_system:job:current:udds:A:all_A
- For all current employees in a division add the 2 digit identifier: uw:ref:hr_system:job:current:udds:A:A07:all_A07
- For a department add the next two digit identifier onto that: uw:ref:hr_system:job:current:udds:A:A07:A0712:all_A0712
- For a subdepartment (a/k/a "group") add the final two digits: uw:ref:hr_system:job:current:udds:A:A07:A0712:A071200:A071200
To navigate job titles ("titles"), pay basis ("pay_basis") and job types ("types") there are folders inside each part of the tree, for example:
- 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 pay basis of "None" (N) -- "$0 job" -- in UW-Madison, uw:ref:hr_system:job:current:udds:A:pay_basis:all_A-N. For a list of job types (A/K/A Empl Class), see HRS Documentation.
- For all people with a title of "Professor" (FA020) at UW-Madison: uw:ref:hr_system:job:current:udds:A:titles:all_A-FA020. For more information on titles, see OHR Documentation.

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 UDDS group after they are gone. If you are using groups for detailed access control, you may need to take this in to account.
If you are tempted to construct a group that excludes "$0 jobs" make sure to think about if you want to exclude $0 jobs, or include people who have a paid job. Most likely it is the latter, so you'll want to expressly include the other pay bases instead of excluding N.
Similarly if you are tempted to exclude "Student Jobs" (SA or SH job types), you'll want to think about if you really mean that, or instead mean to include people who have the other types. Most likely you mean the latter.

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

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