---
title: "Members"
description: "A member is a user account that has been linked to your organization through the invitation process."
---

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

# Members

A **member** is a user account that has been linked to your organization through the [invitation process](invitations.html). The membership record connects the global user identity to your organization and carries metadata like job title and role assignments.

View and manage all members at **Settings → Members**.

## What You See in the Members List

The list is one line per **role assignment** rather than one per person — somebody holding two roles appears twice — and each line carries:

- **Role** — the job the person has been given here. Click it to open the assignment.
- **User** — who holds it.
- **Valid from** and **Valid until** — the window it applies in. An assignment with no end reads *No end date*.
- **Active** — whether it is in force at all.

The list has no searchable column, so the **filter button** is how it narrows: by **Role**, **User**, **Active**, or a **Valid From** / **Valid Until** window ([Working with lists](../getting-started/working-with-lists.html#narrowing-the-list)).

## Role Assignments

Each member can hold one or more **roles**. A role assignment is the link between a user and a role within your organization — it is what controls what the member can see and do.

### Managing Role Assignments

Opening an assignment shows the whole of it on one page: who holds the role, the role itself, whether it is in force, the window it runs for, and who granted it. The person is asked for once, when the assignment is made, and is fixed afterwards — to move a role to somebody else, take this assignment away and make theirs.

From the Members page, you can:

- **Assign roles** — grant a member access to specific features by adding one or more roles.
- **Remove roles** — revoke access. The member remains in the organization but loses the permissions from that role. Useful when someone changes responsibilities.
- **Set validity dates** — make an assignment temporary by specifying a **valid from** and **valid until** date.

### Temporary Assignments

Validity dates let you grant time-limited access without having to remember to revoke it later. Common scenarios:

| Scenario                            | How to set it up                                                                       |
| ----------------------------------- | -------------------------------------------------------------------------------------- |
| **Covering someone on leave**       | Assign their role to the covering person with validity dates matching the leave period |
| **Project-based access**            | Grant elevated permissions for the project duration, they expire automatically         |
| **Onboarding with training access** | Give new hires a broader role for their first 30 days, then it narrows automatically   |
| **Seasonal workers**                | Assign roles that are active only during the busy season                               |

### When Is a Role Assignment Active?

A role assignment is considered **active** when all three conditions are met:

1. The assignment is **enabled** (not deactivated).
2. The current date is **on or after** the valid from date (or no start date is set).
3. The current date is **before** the valid until date (or no end date is set, meaning it is open-ended).

If any condition is not met, the assignment is inactive and its permissions do not apply.

## Tips

- **Review role assignments periodically** — as people change responsibilities, their roles should change too. Stale assignments are a common source of excessive access.
- **Use validity dates proactively** — whenever you know access should be temporary, set an end date up front rather than relying on yourself to remember to revoke it later.
- **Prefer role changes over removal** — when someone moves to a different function, swap their role rather than removing them from the organization. This preserves their membership record and audit history.

<a id="seeing-what-someone-can-actually-do"></a>

## Seeing what someone can actually do

Open a member and switch to the **Effective Permissions** tab. It lists everything that
person can do in this organization as a single set, grouped by module.

This is worth using rather than reading their roles and working it out, because the answer
is a combination of several things: every active role they hold, plus anything currently
delegated to them, minus anything a deactivated role used to provide. The tab shows the
same set the system itself checks against when they make a request, so what you see is
what they can do.

Someone who owns the organization can do everything regardless of the roles listed, and
the tab says so rather than showing a misleadingly short list.

Source: https://docs.beelocity.com/en/access-control/members/index.mdx
