The Grouper team will set up "app stems" and/or "org trees" for you, and work hand-in-hand with you on the technical build; your team will be responsible for designing the policies within your app stem.
What is a Grouper Policy
Policies are rules that determine who is allowed to access specific resources and exactly what they are permitted to do once they are in. While the Grouper team is responsible for the technical build, your team makes the decisions regarding how each policy is designed.
Commonly, different subsets of users have different privileges within a given system or resource. In those situations, the different privileges are mapped to different policies.
Example: Your team manages a new lab resource for dental students. You decide all dental students should have general access to the software, but only a small subset of staff should have administrative rights to the exam module. In Grouper, you represent these two populations—dental students and admins—in separate Access Policy Groups. These groups map to the same resource but grant different levels of permission. In general, Grouper parses user populations into distinct, granular groups that are automatically updated in near real-time as a student's enrollment status changes—for instance, if they drop a course, withdraw from the program, or graduate.
How Grouper Policies Work
In this example, the dental school stakeholders have requested two policies for their lab resource; one for students, one for admins. Each policy leverages 'group math' to build a composite (final) list to ensure the right people are ultimately given the appropriate access.
A. The Allow Factor (The "Starting" List)
The Allow Factor is your primary list of users who are potentially eligible for access. In this example, all dental students are in the initial "allow" list. The Grouper team can work with you to get most levels of granularity to target specific user populations. The "allow" population will include:
Automated Reference Groups: These ensure users are automatically granted access when they join the University and deprovisioned the moment they leave or change status.
Manual/Ad Hoc Groups: These allow you to manually add individuals—such as visiting researchers or late registrants—who may not meet the automated criteria but still require access.
B. The Deny Factor (The "Who Must Not Have It" List)
The Deny Factor is a list of users who must be blocked, even if they appear in the Allow list. This acts as a safety filter to ensure restricted users never get in. This population will include:
Users whose access to University resources have been revoked by a centralized UIS (security) process.
Any person you have manually added to the ad hoc "Deny Users" security group.
C. The Composite Group (The "Final List")
The Composite Group is the result of applying "group math" to the two factors.
The Logic: It uses a Complement operation (Allow list minus Deny list).
The Result: A dynamic, automated list containing only users who are in the Allow group and not in the Deny group.
This group is automatically provisioned to the target endpoint consumed by your application (e.g., Entra ID, AD, or LDAP).
For more about provisioning see Automated Provisioning and Deprovisioning)