How Do Access Groups Work (at a high level)?

How do Access Groups work (at a high level)?

At a high level, Access Groups constitute a filter or sieve between the ID Hub and Consumer namespaces. They are applied during the ID Hub to Consumer mapping jobs. That means a filtered view of the data will be available in the Data Explorer after running a Consumer mapping job.

Since rostering data is hierarchical, Access Groups are also internally hierarchical, and filter different data sets according to ID Hub type-specific rules.

In general, any particular candidate record will be allowed through the sieve if and only if it matches at least one of the active Access Groups.

A candidate record is said to match an Access Group if it matches at least one selected scope for every selected scope type.

For example, if you have a set of campuses selected, then candidate records must be associated with one of the campuses in the list to make it past the filter.

For another example, if you have a set of campuses AND courses selected, then candidate records must be associated with at least one selected campus and at least one selected course to make it past the filter.

What does it mean to match a scope?

A candidate record is said to match a scope if the field value below is equal to the id of the selected scope:

Note that blank cells indicate that the scope type (in the column header) does NOT govern ID Hub records of the type in the leftmost column. That means, for example, that selection of a set of courses will NOT narrow down the set of orgs that are available to downstream applications.

Simple Example

Let us step through what filtering each data set looks like with one example. Suppose you have a single active Access Group with one course scope selected, with the id 1234. In that case, the following records will be available to the downstream consumer (these values are filters that can be used in the Data Explorer, Studio field template expressions, etc.):

Note that:

• Equivalence for multi-valued fields (like user.course and enrollment.course) actually only implies a containment relationship. That is, if at least one element of user.course is equal to 1234, then that user makes it through the filter.

• Blank cells imply that there is no filter; that is, all org and session records are allowed through the filter.

Hierarchical Example

Let’s step through a hierarchical example. Let’s say we have a single active Access Group with one campus scope selected (ABC) and one section scope selected (456). Here is the set of filters for that Access Group:

Disjunction Example

For one more example, we’ll use more than one scope within a single scope type. Let’s say we have a single active Access Group with one district scope selected (DEF) as well as two course scopes selected (345 and 678):

These are all of the rules we need to understand the logic for filtering with Access Groups.

Formal Logic
Note: the governance table referenced below is provided above.