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

# 成员与角色

> 在组织层邀请成员并设定默认角色，需要时在单个业务单元内覆盖它。

成员在**组织**层加入 Orriven，并在那里获得一个默认角色。在每个业务单元内部，
这个角色可以被单独覆盖——收紧或放宽——而不影响这个人在其他任何地方的权限。

## 邀请成员

1. 在控制台的组织区域打开**成员**。
2. 选择**邀请**，输入对方的邮箱，并选定其组织角色。
3. 邀请在被接受之前会显示在**待处理邀请**之中。

成员页面列出组织的全部成员及其默认角色。

## 角色一览

组织层和业务单元层使用同一套角色名：

| 角色         | 适合谁                   |
| ---------- | --------------------- |
| **所有者**    | 账户的主人。完全控制，包括账务层面的决定。 |
| **管理员**    | 运营组织：业务单元、成员、设置。      |
| **策划**     | 搭建和运营活动：票种、议程、邮件、参会者。 |
| **现场工作人员** | 活动当天的工作：签到类操作、参会者查询。  |
| **只读成员**   | 只读。能看，不能改。            |

一个人的**组织角色**是他在任何地方的默认角色；**业务单元角色**只在那一个单元内生效。

## 角色在业务单元内如何解析

当成员打开一个业务单元时，其实际角色按以下顺序决定：

1. **组织的所有者和管理员永远有权访问**，并以该角色进入。这是安全阀——
   组织永远不会被锁在自己的业务单元之外。
2. 其次是**在该业务单元内被明确授予的角色**。单元的**成员**页面上，「此处角色」一列显示它；
   没有覆盖的显示为*继承*。
3. **否则继承组织角色** —— 除非该业务单元处于**受限**模式：此时没有回退，这个人完全无法访问。

## 设置单元内角色

打开业务单元，进入它的**成员**页面。每一行显示这个人的组织角色和此处角色。
选一个不同的角色即为覆盖；选择**恢复为组织角色**则删除覆盖、回到继承。

## 对搭建团队意味着什么

给管理员的几个实际例子：

* **大多数公司只需要组织角色。** 在组织层给策划们分配策划角色，让所有业务单元继承。
  覆盖是例外手段，不是常规操作。
* **只参与一个项目的外包**：以组织**只读成员**身份邀请进来，再在他工作的那一个业务单元内
  授予**策划**。其他任何地方他都只能看。
* **保密单元**：在单元设置中开启**受限**，然后逐个给应当在内的人授予角色。
  其他人——无论组织角色是什么——都看不到这个单元的存在。组织的所有者和管理员除外。
* **局部降权**：一位在全组织受信任的策划，若只应旁观某个敏感单元，可以在那里覆盖为
  **只读成员**，其他地方仍是策划。

## 注意事项

* **无权访问表现为「未找到」，而不是「无权限」。** 对受限单元没有授权的成员，列表里看不到它，
  访问它的 URL 会得到未找到页面。这是有意的：这个单元的存在本身就是机密。
* **覆盖只作用于一个单元。** 在某个业务单元授予策划，对其他任何单元不产生任何影响。
* **无法用受限模式挡住所有者和管理员。** 受限只是切断普通成员的组织角色回退；
  所有者和管理员的访问是设计上保证的。
* **没有覆盖就意味着继承。** 恢复角色不等于把人移出单元——这个人仍然拥有其组织角色
  （和单元访问模式）赋予的一切。
* 组织成员资格在组织的**成员**页面管理；业务单元的页面只决定*角色*，从不决定谁属于公司。

<Tip>
  每一次角色变更——邀请、覆盖、受限开关——都会记录在[审计日志](/zh/organization/audit-logs)里，
  你随时可以回答「是谁、在什么时候给了这个人访问权限」。
</Tip>