> ## 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 people who end up with access is the app's
**effective users**.

## Assign groups

On the application's page, open its **assignments** and add the **groups** that
should have the app. Everyone in an assigned group gets access, and membership
stays in sync as people join or leave the group.

When the app uses [roles](/en/identity/applications/roles-and-bundles), you assign
each group to one of the **application's roles** - the role *within that app*
(for example, admin or member), conveyed to the app at sign-on. This is the app's
own role, not the person's Iru role.

```mermaid theme={null}
flowchart LR
  u2["User"] --> g1["Group"]
  u3["User"] --> g1
  g1 -->|"assigned (to an app role)"| 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 person from the
    group grants or revokes the app automatically - 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 people's 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 effective users and groups

Direct user assignments and group memberships combine into the app's
**effective** access. The application's page lists them so you can confirm
exactly who has the app:

* **Effective users** - every person with access, whether assigned directly or
  through a group, with the date their access began.
* **Effective groups** - every group that resolves to access for the app.

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 - unassigning them directly and
  removing them from every assigned group - drops them from the effective set,
  and they can no longer sign in to the app.
</Note>

## Roles within an application

Assignment decides who can *reach* an app; some apps also expect a **role** for
each person (administrator, member, and so on). Iru can assert a role based on
group membership, and vary session length and risk by role. See
[Roles & Bundles](/en/identity/applications/roles-and-bundles).

## 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 people must prove to sign in.
  </Card>
</CardGroup>