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.
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.
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.
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.
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. Title codes are truncated to 5 characters per OHR because the 6th character reflects only benefits information, not title, for example a group for
AD026contains people with titles
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, pay basis, 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:pay_basis:all_A-N. 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.
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:
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. 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:
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"