# Infor Birst Dynamic Groups for Row-Level Data Access

> Source: https://netray.co/erp-help/infor-birst-dynamic-groups-row-level-security
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

In Birst you control which rows a user sees by tying a data filter to user or group membership. A dynamic group is the pattern where membership comes from data, for example a security table mapping users to plants, rather than from groups you maintain by hand.

## Kind

how-to

## System

infor-os

## Erp

Infor Birst

## Module

Space Administration / Security

## Query

infor birst dynamic groups

## Alternate Queries

- birst dynamic groups row level security
- birst row level security
- birst data filters by user

## Applies To

Infor Birst spaces. Menu names differ by version, so use this as the pattern and confirm labels in your tenant.

## Steps

### Set up data-driven row-level access

**Items:**

- Decide the restricting attribute, for example plant, business unit or customer group.
- Create a security table with one row per user and allowed value, and load it into the space.
- Add the restricting attribute to the relevant fact tables so rows can be matched.
- Define a data filter or group-based filter on the model that matches the logged-in user to the security table.
- Assign the filter to the groups that should be restricted and leave administrators unrestricted deliberately.
- Test as a restricted user and as an unrestricted one, comparing totals.
- Document the table, the filter and who owns the mapping, and reload the security table on a schedule.

## Sections

### Static versus dynamic

**Body:**

- Static groups are maintained in administration and each carries a fixed filter. They are simple but do not scale when you have hundreds of users and frequent changes.
- A data-driven approach moves the mapping to a table you can refresh from HR or ERP, so access follows the source of truth.

### Testing properly

**Body:**

Test with real restricted users, not only admins, and compare a total against an unrestricted total. A filter that matches nothing returns an empty report, while one that fails open shows everything, and only the second is a security problem.

Test dashboards and drill-through, not just one report, since each can use different joins.

### Operating it

**Body:**

Treat the security table as controlled data. Changes should follow an approval path and be logged. If Birst data comes from ERP, align roles with ERP roles so the two do not drift.

## Pitfalls

- Filtering only on a dimension and leaving a fact table path unrestricted.
- Testing only as an administrator.
- Hand-maintaining mappings that go stale.
- Letting an empty match fall through to show all data.

## Ai Angle

When users ask questions in natural language over the same data, the assistant must carry the same row-level rules. A grounded assistant runs with the user's identity, applies the same restrictions and can run fully on-prem where policy requires.

## Faq

### What is a dynamic group in Birst?

**Answer:** A group whose effective data access is driven by data, such as a security table, instead of fixed manual assignment. It is a design pattern built from groups, filters and a mapping table.

### How do I test row-level security?

**Answer:** Log in as restricted users and compare totals with an unrestricted view, across reports and dashboards.

### Can one user belong to several restrictions?

**Answer:** Yes, by having multiple rows per user in the security table, giving access to multiple values.

### How often should the mapping reload?

**Answer:** Align it to how fast roles change, commonly daily, and trigger a reload on important changes.

## Search terms

infor birst dynamic groups, birst row level security, birst data filter, birst security table, infor birst groups, birst user access

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json