---
title: "How Do Access Groups Work (at a high level)?"
slug: "how-do-access-groups-work-at-a-high-level"
description: "Access Groups constitute a filter or sieve between the ID Hub and Consumer namespaces.They are applied during ID Hub to Consumer mapping jobs."
updated: 2022-11-14T16:53:54Z
published: 2022-11-14T16:53:54Z
canonical: "help.rapididentity.com/how-do-access-groups-work-at-a-high-level"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://help.rapididentity.com/llms.txt
> Use this file to discover all available pages before exploring further.

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

![Screen Shot 2022-11-14 at 9.57.02 AM.png](https://cdn.document360.io/4d958006-b877-42af-8de5-00e3bb7fe41d/Images/Documentation/Screen%20Shot%202022-11-14%20at%209.57.02%20AM.png)

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.): ![Screen Shot 2022-11-14 at 10.02.55 AM.png](https://cdn.document360.io/4d958006-b877-42af-8de5-00e3bb7fe41d/Images/Documentation/Screen%20Shot%202022-11-14%20at%2010.02.55%20AM.png)

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: ![Screen Shot 2022-11-14 at 10.05.07 AM.png](https://cdn.document360.io/4d958006-b877-42af-8de5-00e3bb7fe41d/Images/Documentation/Screen%20Shot%202022-11-14%20at%2010.05.07%20AM.png)

**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): ![Screen Shot 2022-11-14 at 10.05.54 AM.png](https://cdn.document360.io/4d958006-b877-42af-8de5-00e3bb7fe41d/Images/Documentation/Screen%20Shot%202022-11-14%20at%2010.05.54%20AM.png)

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.

![image.png](https://cdn.document360.io/4d958006-b877-42af-8de5-00e3bb7fe41d/Images/Documentation/image%28270%29.png)