角色与权限
Astra Growth · Management System Brief

01|角色与权限

Astra Growth 通过业务角色、治理角色与多维权限模型,控制不同用户能够查看和操作的 Lead 范围。

ACCESS & GOVERNANCE / 01
A

角色体系

业务角色与治理角色分离,职责清晰、权限独立

Business Operations

业务运营角色

从执行到管理
Sales销售
直接跟进与转化
  • 领取
  • 跟进
  • 状态更新
  • 转化推进
Team Leader销售团队主管
团队 Lead 运营负责人
  • 线索分配
  • 线索使用
  • 过程管理
  • 团队表现
Business Manager各级管理人员
辖区 Lead 分配
  • 线索分配
  • 审批管理
  • 异常处理
  • 结果分析
Management管理层
只读经营视角
  • 经营分析
  • 转化漏斗
  • 组织表现
只读 / 聚合
Management 不属于 Lead 业务执行链

管理层以只读方式观察经营与组织表现,不直接参与 Lead 操作和分配。

B

角色权限矩阵

不同角色在联系方式、操作、分配和治理方面的权限边界

Enterprise Access Matrix
拥有权限条件授权只读 / 聚合不可访问无该能力
角色Lead 数据范围联系方式查看权限Lead 操作权限Lead 分配能力系统 / 数据治理权限说明
Sales销售
仅分配到本人的 Lead接受 Lead 后可查看本人范围负责本人 Lead 的跟进与转化
Team Leader销售团队主管
本团队仅分配到自己且接受的可查看本人范围团队内分配团队管理配置团队 Lead 分配与过程管理
Business Manager各级管理人员
所辖组织范围不可查看不可操作跨下级组织分配业务规则配置规则分配、异常处理与运营分析
Management管理层
所辖范围聚合数据不可查看不可操作经营分析与组织绩效监控
System Engineer系统工程师
无访问权限不可查看不可操作系统治理系统配置与权限治理
Data Engineer数据工程师
无访问权限不可查看不可操作数据治理数据任务、质量与重复治理
C

多维联合控制权限

用户最终能够访问和操作的内容,由多个维度联合判断

用户角色Role

决定用户基础权限

Sales / Admin / Management

组织范围Organization Scope

限定能够访问的组织层级

Team / Country / Region

Lead 归属Lead Ownership

判断 Lead 当前责任关系

本人 / 团队 / 辖区

操作权限Action Permission

决定允许执行的动作

查看 / 编辑 / 分配 / 回收

字段权限Field Permission

控制可以查看的字段

联系方式 / Notes / 敏感字段

最终可访问的数据与功能

只有当所有权限条件同时满足时,用户才能访问或操作对应内容。

Astra Growth · Vertical Sales Intelligence

03|Sales Copilot

一个真正理解每条 Lead 的垂直 Sales Copilot

围绕每条 Lead 工作,在授权范围内读取客观数据、AI 分析结论与 Sales 历史互动记录,形成完整 Lead Context,并持续提供触达、沟通和跟进建议。

让 Sales 在每一次触达和跟进前,都能够基于完整 Lead Context 获得下一步行动建议。
LEAD CONTEXT & REASONING / 03
A

Sales Copilot 工作原理

围绕单个 Lead 的统一上下文

Lead 客观数据OBJECTIVE DATA
  • 平台与账号信息
  • 地区与语言
  • 公开联系方式
  • 粉丝 / 观看 / 互动指标
  • 历史公开内容
  • 私域渠道
  • Broker / Trading 相关公开信号
  • 当前 Lead 状态
  • 历史分配与跟进记录
Objective Data
Lead 画像LEAD PORTRAIT
  • CFD 相关性
  • 内容垂直度
  • 内容质量
  • 影响力
  • 私域承接能力
  • Broker 合作经验
  • 潜在 IB 价值
  • 核心优势
  • 风险信号
  • 推荐合作切入点
基于大量准确标签进行的画像推断
Sales × Lead 最近互动INTERACTION CONTEXT
  • Sales 发送消息
  • Lead 回复
  • 当前沟通渠道
  • 最近一次互动
  • 跟进 Notes
  • 已确认信息
  • 待确认问题
  • 当前沟通阶段
  • Lead 状态变化
Latest Interaction Context
04 · LLM REASONING ENGINE

Large Language Model

上下文理解 · 信息关联 · 推理 · 建议生成

  • 综合不同来源的信息
  • 理解 Lead 当前状态
  • 识别已确认与尚未确认的信息
  • 关联历史互动
  • 判断当前最合适的沟通阶段
  • 生成下一步销售建议
  • 随最新互动重新计算建议
Astra Growth · Lead Lifecycle Governance

02|Lead 流转规则

从分配到跟进、转化与回收的完整 Lead 生命周期

Astra Growth 通过责任池、组织分配、销售状态、生命周期和回收机制,对 Lead 的整个使用过程进行统一管理。

LIFECYCLE & CONTROL / 02
A

主流转链路

Lead 从总池进入业务分配、Sales 跟进与最终归档或回收

01

Lead 导入总池

02

制作业务分配批次

03

组织节点分配

04

分配至 Sales

05

Lead 标记

06

锁定并跟进

07

建联 / 质量问题

08

感兴趣

09

成功 / 失败

10

归档或回收

回收后重新具备分配条件的 Lead,可再次进入总池。
B

Sales 状态机

有效、无效与质量问题分支

建联过程中也可转入 Lead 质量问题;质量判断、建联与感兴趣阶段均可标记为 Lead 质量问题,每一步操作都会被完整记录。
C

回收机制

回收总池的三种处理状态

回收总池

可分配

重新进入 Lead 导入总池

待验证

重新验证后决定去向

无需分配

进入无效线索 / 历史数据库,用于历史查询与去重

回收时保留历史分配记录、原 Sales、回收原因与最近跟进情况。
D

关键时间规则

15

组织节点分配期限

每 7 天提醒一次;超时回到上一级节点。

15

Sales 未标记回收

超时回收到组织树上一级节点。

2

无效 Lead 回收

写入回收池。

6个月

Sales 最长生命周期

从团队管理员分配给 Sales 当天开始计算。

延期 1个月

在途状态可申请延期

原因必填,由上级审批。

E

关键管理规则

RULE 01

团队管理员自分配限制

可设置比例上限,默认 20%。

RULE 02

Lead 质量问题

需要标准化原因、修复状态与是否可重新分配。

RULE 03

Lead 三层去重

Account ID去重简介特征去重标准化联系方式去重

RULE 04

UID 真实性验证

UID 可与公司内部数据库校验,返回 Yes / No;技术可行性待确认。

Astra Growth · Security Architecture & Access Governance

04|数据安全

从部署、访问到敏感数据使用,建立全链路安全控制

通过公司受控部署、身份认证、多维权限控制、敏感字段保护和全链路审计,限制 Lead 数据的访问、使用和流转。

让 Lead 数据只在授权范围内被正确的人、以正确的方式访问,并确保所有关键操作可追溯。
DEFENSE IN DEPTH / 04
A

安全控制体系

从环境到数据形成多层防护

01

公司受控部署

  • 核心数据库
  • 数据访问接口
  • 审计服务

核心数据库部署在公司受控服务器环境中,并限制数据向个人设备和非授权环境流转。

02

身份认证

  • JWT
  • bcrypt
  • 登录失败锁定
  • IP 异常尝试限制
  • Token 有效期与刷新

首先确认当前访问者身份。

03

多维联合控制权限

  • Role × Organization Scope
  • Lead Ownership
  • Action Permission
  • Field Permission
Default Deny

未明确授权的数据和功能默认不可访问。

04

Lead 数据隔离

按照组织结构和业务责任限制可访问的 Lead 范围。

系统同时控制“可以看哪条 Lead”。

05

联系方式保护

联系方式默认脱敏。

完整联系方式只有在业务权限满足并完成 Lead 锁定后才允许返回。

06

审计追溯

关键访问、业务操作与安全变更全部保留记录。

B

Lead 数据隔离

业务数据范围与系统治理职责相互隔离

Business Roles

Sales

仅访问分配到本人且符合授权条件的 Lead。

Team Leader / Business Manager

按照团队或所辖组织范围访问相应 Lead 数据。

Management

仅查看授权范围内的聚合经营数据。

  • 不查看联系方式
  • 不直接操作 Lead
Governance Roles

System Engineer

  • 用户
  • 组织
  • 角色
  • 权限
  • 系统配置
  • 审计策略
Lead 数据:无访问权限联系方式:无访问权限

Data Engineer

  • 数据导入任务
  • 数据质量指标
  • 重复治理规则
  • 后台数据任务
Lead 数据:无访问权限联系方式:无访问权限
系统治理能力和数据治理能力不会自动获得 Lead 业务数据访问权限。
C

敏感字段保护

同时控制 Lead 范围与可见字段

01联系方式默认脱敏
完整信息+65 9123 4567
默认展示+65 **** 4567

Phone、Email、Telegram、WhatsApp 等属于高敏感业务字段。只有满足对应业务权限后,系统才允许返回完整信息。

02字段级权限
基础信息AI 分析Sales Notes联系方式历史跟进管理字段

不同角色获得不同字段集合。

字段权限由 API 层统一执行。
03行级权限
品牌区域国家团队Sales

用户可访问的 Lead 范围按照组织与责任维度控制。

系统同时控制“可以看哪条 Lead”以及“这条 Lead 的哪些字段可以看”。
D

联系方式查看与 Lead 锁定

PII LOCK
01

权限校验

确认当前用户是否有资格访问该 Lead。

02

归属检查

确认 Lead 当前状态以及是否允许当前 Sales 接受。

03

Lead 锁定

建立当前 Sales 与 Lead 的有效责任关系。

04

返回完整联系方式

只有锁定成功后,才返回未脱敏联系方式。

05

记录审计事件

  • 查看人
  • Lead
  • 时间
  • 查看字段
  • 当前归属状态
完整联系方式的查看必须建立在明确的业务责任之上。
E

访问与数据流转控制

批量 Lead 读取

限制异常批量访问。

联系方式批量查看

限制短时间内大量查看敏感联系方式。

数据导出

严格控制数据导出能力。

非授权 API 调用

阻断未授权接口访问。

异常高频访问

检测异常行为。

系统重点控制数据真正离开系统的方式。
F

全链路审计

所有关键动作均保留记录

身份与访问

  • 登录
  • 登录失败
  • Token 异常
  • 异常访问

Lead 与联系方式

  • Lead 查看
  • 联系方式查看
  • 敏感字段读取
  • 异常高频查看

业务操作

  • 分配
  • 改派
  • 回收
  • 状态变化
  • 归档

系统治理

  • 用户变化
  • 角色变化
  • 权限变化
  • 参数变化
  • 安全策略变化
·在什么时间·对哪条数据·执行了什么操作
G

数据完整性

Append-only History

关键业务历史采用追加式记录

持续保留以下关键业务与治理变化:

  • 分配
  • 改派
  • 回收
  • 联系方式查看
  • 状态变化
  • 权限变化
如果历史记录出现错误,通过新增纠错事件引用原记录完成修正。原始历史持续保留,不直接覆盖或删除。
Astra Growth · Event-Driven Architecture & AI Runtime

05|技术架构

事件驱动、策略控制与 AI Runtime,构建可扩展的 Lead 运营底座

架构围绕业务一致性、权限安全、组织扩展、AI 可替换和生产环境稳定性进行设计。

EVENT-DRIVEN & AI RUNTIME / 05
A

系统架构与数据库架构分层协同

系统负责业务流程与服务编排,数据库负责数据持久化与一致性约束;两者通过 API、ORM 和事件机制协同,但职责边界保持独立。

SYSTEM ARCHITECTURE · 系统架构

应用、服务与业务运行

覆盖多源接入、身份权限、领域服务、事件自动化、AI Runtime、任务调度和可观测性,负责业务能力与流程编排。

DATABASE ARCHITECTURE · 数据库架构

数据存储、模型与约束

覆盖 PostgreSQL、核心表关系、索引、RLS、唯一约束、JSONB,以及 progress_events / audit_logs 追加式账本。

01 · 系统技术架构业务能力、服务编排与运行治理
CHANNEL INTAKE · 多源接入X / Facebook / Excel / 销售反馈 / OpenAPI
ACCESS GATEWAY · 接入网关Nginx + HTTPS · REST / OpenAPI · 批量导入
IDENTITY & ACCESS · 身份与权限JWT / bcrypt · RBAC + ABAC · 字段 / 行级范围
EXPERIENCE · 体验与管理端React 18 + TypeScript · 销售 / 管理员 / 看板
01多源采集
02批次解析
03数据治理
04Lead 主数据
05组织分配
06销售跟进
07转化 / 回收
DATA GOVERNANCE · 数据治理服务
Validate字段与格式校验
Normalize标准化
Deduplicate跨平台去重
Reconcile匹配 / 合并
Rollback批次回滚
Quality血缘与质量评分
SLA · Retry · DLQ · 错误日志 · 异常检测 · 人工干预
DOMAIN SERVICES · FastAPI / Python 3.11
Lead Service主数据与状态
Import Pipeline导入与治理
Assignment Engine分配与回收
Follow-up Engine跟进与提醒
Tag / Profile Graph标签与画像
Reporting Query报表与查询
依赖注入 · 中间件 · 限流 / 熔断 · OpenAPI · 版本与 Schema 校验
AI Runtime 与策略决策
CopilotKitSales Copilot 运行时
LiteLLM统一模型接口
可替换模型效果 / 成本 / 地区策略
Policy Engine权限与分配规则
Idempotency防止重复写入
Optimistic Lock并发状态保护
模型只提供建议;授权、状态转换和数据写入仍由业务服务控制
EVENT AUTOMATION · ACID Write Path → Transactional Outbox → Async Consumers主数据写入、分配与任务在事务内提交;Outbox 使用 INSERT-ONLY Ledger、Idempotency-Key 和顺序保证,异步驱动通知、Todos / Tasks 与 Audit Trail。
任务调度APScheduler / Worker · SLA、提醒、回收
缓存与迁移Redis Cache · Alembic
可观测性Metrics · Logs · Traces · Alerts · Dashboards
部署运行Docker Compose · 灰度 · 回退 · 对账
安全边界TLS 1.2+ · 最小权限 · 脱敏 · 审计
同步 API异步事件RBAC + ABACDefault DenyAt-least-onceRetry / Backoff / DLQAI 模型解耦
系统架构产生命令、查询、权限决策与业务事件
数据访问契约SQLAlchemy 2.0 Async · ACID 事务边界 · Transactional Outbox · Schema Migration
数据库架构负责持久化、约束、索引、隔离与审计账本
02 · 数据库技术架构数据模型、关系、约束与查询治理
DATA & INSIGHT · PostgreSQL 16 · Lead 统一数据底座SQLAlchemy Async / Alembic · Encryption at Rest · UTC Timezone
lead_accountsaccount_no
platform / platform_account_id
import_batch_id
stage / score
Lead 主实体
import_batchessource
status
created_at
rollback_ref
导入批次
teamsname
region
parent_id
closure_path
组织树
system_usersuser_name / email
role_id
team_id
status
身份主体
lead_assignmentslead_account_id
assignee_user_id
due_at
is_current
唯一有效归属
progress_eventslead_account_id
event_type
content JSONB
event_at
INSERT-ONLY
lead_taskslead_account_id
owner_user_id
status
due_at
SLA 任务
audit_logsactor_user_id
resource / action
status_code
created_at
INSERT-ONLY
user_notificationsrecipient_user_id
severity
payload JSONB
read_at
通知投递
outbox_eventsaggregate_id / type
payload JSONB
status / retry_count
occurred_at
事务事件
import_batches 1:N lead_accounts · teams 1:N system_users · lead_accounts 1:N assignments / progress / tasks · system_users 1:N assignments / tasks / audit / notifications
完整性与并发PK / FK · Partial Unique Index · 乐观锁 · 单一有效归属
索引与检索JSONB · GIN Index · 全文检索 · 分区 / 时间索引
数据安全RLS · 最小权限 · 静态加密 · 敏感字段脱敏
历史与恢复Append Only · 审计账本 · 在线对账 · 备份 / 回滚
PostgreSQL 16JSONB / GINClosure TableRow-Level SecurityPartial UniqueAppend Only审计可追溯
B

四类核心架构能力

01 · 一致性
事务一致性

Transactional Outbox、唯一约束、乐观并发和幂等机制共同保证关键业务动作完整可靠。

02 · 可追溯性
事件可追溯

分配、PII 查看、跟进和生命周期变化以事件方式保存,可完整恢复历史业务轨迹。

03 · 治理能力
策略化权限治理

RBAC + ABAC、字段级和行级权限在 API 层统一执行,权限与页面展示解耦。

04 · AI 演进
AI 可演进

通过 CopilotKit + LiteLLM 将业务能力与具体模型解耦,支持后续模型替换和多模型策略。

C

组织变化不需要重构权限系统

Closure Table 将现实组织结构映射为通用层级模型,支持品牌、大区、国家、团队等不同组织形式。

现实组织
品牌
大区
国家
团队
销售
系统抽象
Org L1
Org L2
Org L3
Org L4
User
D

技术选型服务于业务目标

系统前端与体验
React 18前端应用
TypeScript类型安全
Vite构建工具
React Query数据交互
系统后端与运行
FastAPI领域服务与业务 API
APSchedulerSLA 与定时任务
Nginx网关与访问边界
Redis会话与热点缓存
数据库与数据访问
PostgreSQL 16核心关系数据库
SQLAlchemy 2.0 Async异步 ORM / 事务
AlembicSchema 迁移
JSONB / GIN / RLS扩展、检索与行级隔离
AI 与系统治理
CopilotKit + LiteLLMAI Runtime 与模型抽象
RBAC + ABAC系统授权策略
Docker Compose容器化部署
Prometheus + Logs可观测与运行治理