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

# Org Chart and Teams

> Model teams, managers and team leads, route approvals up the requester's reporting chain or to a team, preview who is asked, and filter lists to your team

The org chart records who reports to whom and which teams people work in. Approval rules use it to ask the right person for each request: a rep's own manager, the managers above them, their team's leads, or a team's Manager. You don't keep a separate list of approvers per rep, and approvals keep working when people move teams or leave. The chart also powers the **My team** filter on the Accounts and Subscriptions lists. Use this page when you set up teams and managers, or when you build approval rules that route by requester.

For the approval model, see the [Approvals overview](https://alguna.com/docs/approvals/overview.md). For conditions and rulesets, see [Approval rules](https://alguna.com/docs/approvals/approval-rules.md). The org chart is dashboard-only and has no public API.

***

## Where it lives

The org chart is under **Settings → Admin → Users → Org chart**. Viewing and editing it both need the Manage Users permission, which the built-in Admin role has.

The page has two views:

* **People**: the reporting chart. Filter it to one team, and hover a person to highlight their chain. A tray lists anyone with no manager and anyone in a reporting loop.
* **Teams**: a table of teams with each team's **Manager**, **Members**, **Parent** and **Roles it carries**. **New team** creates one.

The **Members** page next to it, under the same **Users** menu, shows each person's **Home team** and **Manager**. **Edit in org chart** on a row opens that person.

***

## Teams

A team has a name, a colour, and optionally:

* **Parent teams**: where the team sits in the chart. A team can have several parents. Exactly one is **primary**, and the primary parent decides whom the team's Manager reports to. A team with no parent is at the top of the chart.
* **Manager**: the default manager of everyone whose home team this is. The Manager does not have to be a member of the team.
* **Members**: each member can be marked **Lead**. Leads matter only to approval rules that ask team leads.
* **Roles it carries**: [custom roles](https://alguna.com/docs/concepts/organizations-and-environments.md) that every member gets. With **Applies to sub-teams** on, members of every team below get them too. A custom role cannot be deleted while a team carries it.

Changes in the team drawer save as you make them. Deleting a team removes its memberships. Its members lose it as their home team, and with it their default manager. Its sub-teams move to their next parent, or to the top of the chart.

***

## People and managers

Each person has:

* **Home team**: at most one. Their home team's Manager is their default manager.
* **Reports to**: **Follow the team** (the default) or **Choose a person**. Choose a person for someone who reports outside their team. A manager set this way is marked as set by an admin.
* **Additional managers**: optional, in order. Approval rules that include additional managers ask them after the main manager.
* **Teams**: other teams they belong to. These count for team approvals, roles and leads, but not for who their manager is.

A person's manager is worked out in this order:

1. The person an admin chose under **Reports to**.
2. Otherwise, the Manager of their home team. A team's own Manager reports to the next Manager up.
3. Otherwise, the nearest Manager up the chain of primary parent teams.

Someone with no home team and no chosen manager has no manager.

When the home team changes, the drawer asks what should happen to the teams this person manages: keep managing them, hand them to someone else, or leave them without a Manager. It also asks what should happen to anyone an admin pointed at them. Changes in the person drawer are saved together with **Save changes**.

Saving is refused when it would make a loop: a team under itself, a person reporting to themselves, or a chain of managers that comes back round.

***

## Routing approvals with the org chart

Approver groups are set on each [approval rule](https://alguna.com/docs/approvals/approval-rules.md) under **Settings → Workflows → Quotes → Approvals**. The **Approvers** picker of a group offers these sources:

| Source | Who is asked |
| - | - |
| **Requester's managers** | The manager of the person who submitted the deal, then the next manager up, one level at a time |
| **Requester's team leads** | The leads of the requester's home team |
| **Approvers by requester** | People you map to each requester |
| **A team** | The team's current members, optionally including sub-teams |
| **A team's leads** | The team's leads |
| **A team's Manager** | The team's Manager |
| **Named people** | The people you list |
| **Everyone with the Approver role** | Anyone who can approve |

**Requester's managers** has two more settings:

* **How far up**: **Their manager only**, **Up to a number of levels**, or **All the way to the top**. Each level is asked only after the level below approves, and any one manager at a level is enough.
* **Who counts as a manager**: **Only their main manager**, or **Also additional managers**, up to a number you set.

### Who can actually approve

Only people with the Manage Approvals permission are ever asked. The built-in role that has it is **Approver**. Admins do not have it by default, and a custom role can also grant it, including a role a team carries. A manager or lead without the permission is skipped. Turn on **The requester can't approve their own request** to leave the requester out too. For managers and leads, if the requester is the only one found, the next level up is asked instead.

### Fallback

Every group that uses the org chart needs an **If nobody is found** fallback. The fallback can be **Everyone with the Approver role** (recommended), named people, a role, or a team. It answers when the source finds nobody who can approve: a requester with no manager, an empty team, or a team that was deleted. An enabled rule cannot be saved with a fallback that names nobody who can approve.

### Steps

Groups can be placed in **Step 1**, **Step 2** and so on. A step opens only after the step before it approves. A rule with more than one step requires all of its groups to approve. A group in a later step always needs a fallback.

### Previewing who is asked

While you edit an org chart group, **Preview** shows who the group would ask **For a request from** a person you pick, level by level, including when the fallback would answer. Click a person to see why they are included, or why they cannot approve. The rule's card on the canvas shows the same people.

***

## When the chart changes

Who is asked is fixed when a step or a manager level opens. Editing the chart afterwards does not move requests that were already sent, with these exceptions:

* **An approver is deactivated.** Their pending requests move to the next person the rule would ask, or to the fallback.
* **Team membership changes on a team source.** A step that asks **A team** follows the team as it is now. A new member is asked, and someone who left has their request cancelled. If the team is left with nobody, the fallback is asked.

Deactivating a user also removes them from the chart, so check the teams they managed and give them a new Manager.

***

## My team filter

The Accounts and Subscriptions lists have a **My team** filter for anyone who has people reporting to them. Your team means you and everyone below you in the reporting chain, at every level. It follows reporting lines, not team membership.

* On **Accounts**, it keeps accounts whose owner or CSM is in your team.
* On **Subscriptions**, it keeps subscriptions whose owner is in your team.
* **Include additional managers** adds the people you are an additional manager for.

Records with no owner are not in team views.

***

## Next steps

> [card] [Approval rules](https://alguna.com/docs/approvals/approval-rules.md)
>
> Conditions, priority and rulesets.

> [card] [Approval flows](https://alguna.com/docs/approvals/approval-flows.md)
>
> How groups decide and how flows are audited.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.