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

# Assigning access

> Grant an application to groups in Iru Identity, review effective users, and learn why group-based assignment scales better than direct user assignment.

Adding an application makes it available in your tenant, but no one can reach it
until you **assign access**. You grant access by assigning **groups** to the
app; access follows group membership, so there are no per-user app assignments
to maintain. The fully-resolved set of users who end up with access is the app's
**effective users**.

## Assign groups

You grant access only by assigning **groups**. On the application's **Assignments**
tab, choose **+ Assignment**:

* **Group:** the group that should have the app.
* **Roles:** the role or roles applied to that group.

Everyone in the assigned group gets access. The **group** determines who can
reach the app; the **roles** you select apply to that group and are asserted at
sign-on. They do not grant access on their own. Membership stays in sync as users
join or leave the group.

<Note>
  You cannot assign individual users to an application, and you cannot grant
  access by role alone. Access always follows group membership.
</Note>

```mermaid theme={null}
flowchart LR
  u2["User"] --> g1["Group"]
  u3["User"] --> g1
  g1 -->|"assigned"| app["Application"]
  app --> eff["Effective users<br/>(everyone with access)"]
```

<Tip>
  Combine an [authentication policy](/en/identity/authentication/authentication-policies)
  with assignment: assignment decides **who can reach** the app, and the policy
  decides **what they must prove** to sign in.
</Tip>

## Prefer group-based assignment

Access is always granted through **groups**, so it follows your directory
membership automatically; there are no per-user app assignments to track.

<CardGroup cols={2}>
  <Card title="Access follows membership" icon="users">
    When access is granted through a group, adding or removing a user from the
    group grants or revokes the app automatically, with no per-app edits.
  </Card>

  <Card title="Less to maintain" icon="broom">
    One group can be assigned to many apps. You manage access by editing the
    group, not by touching every application.
  </Card>

  <Card title="Automatic with Auto Groups" icon="wand-magic-sparkles">
    An [Auto Group](/en/identity/directory/auto-groups) updates its own
    membership from an attribute rule, so access tracks users' profiles
    (department, role, location) with no manual steps.
  </Card>

  <Card title="Clear and auditable" icon="list-check">
    Reviewing one group's membership is easier than reconciling individual
    assignments across many apps.
  </Card>
</CardGroup>

For how to build and manage groups, see
[Groups](/en/identity/directory/groups) and
[Auto Groups](/en/identity/directory/auto-groups).

## Review assignments and effective users

On the **Assignments** tab, the table lists each **group** assigned to the app
and the **role** or roles applied to that group.

To confirm exactly who has access, open the **Effective Users** tab. It shows
every user with access through an assigned group, with the date their access
began. This resolved view is the source of truth for who can sign in, and (for
apps with [provisioning](/en/identity/applications/provisioning), who gets an
account created in the app.

<Note>
  Removing someone's last path to access (removing them from every group
  assigned to the app, or unassigning those groups from the app) drops them from
  the effective set, and they can no longer sign in to the app.
</Note>

## Roles within an application

Some apps expect a **role** at sign-on (administrator, member, and so on), not
just identity. When you choose **+ Assignment**, the **Roles** field applies a
role to the group you selected. Define the available roles and how they are
asserted on the application's **Roles** tab. See
[Roles & Bundles](/en/identity/applications/roles-and-bundles).

<Note>
  When the **role assertion method** is set to **None**, only the **Default**
  role can be assigned to groups on the **Assignments** tab.
</Note>

## Favorites

End users can mark the apps they use most as **favorites** from their app dashboard,
which pins those apps for quick access. Favorites are a personal convenience and
do not change who is assigned or what access anyone has.

## Where to go next

<CardGroup cols={2}>
  <Card title="Roles & Bundles" icon="user-tag" href="/en/identity/applications/roles-and-bundles">
    Assert a role to the app and vary session length and risk by role.
  </Card>

  <Card title="Groups" icon="users" href="/en/identity/directory/groups">
    Create the groups you assign to applications.
  </Card>

  <Card title="Auto Groups" icon="wand-magic-sparkles" href="/en/identity/directory/auto-groups">
    Drive group membership (and therefore access) from attribute rules.
  </Card>

  <Card title="Provisioning" icon="arrows-rotate" href="/en/identity/applications/provisioning">
    Turn assignment into real accounts in the app, created and removed as access
    changes.
  </Card>

  <Card title="Authentication policies" icon="shield-halved" href="/en/identity/authentication/authentication-policies">
    Decide what assigned users must prove to sign in.
  </Card>
</CardGroup>