前言：

oracle fusion cloud applications suite针对不同的业务模块都有特别的安全设计。也就是针对不同的业务模块有不同的数据安全策略。

基于以上的修正，重新提供 “在 oracle fusion cloud applications suite 中，假如客户购买/订阅了 如何实施UX(CRM) 系统的安全（用户，角色，授权）？”

在Oracle Fusion Cloud Applications Suite (云原生版本)中，订阅了 UX (CRM/CX，现称Oracle Fusion Sales & Service / CX Cloud) 后，实施系统的完整安全体系（用户、角色、授权）需要将抽象角色（身份）、工作角色（职能）与云端分派引擎（数据授权）完美结合。

以下是修正并补全后的完整实施路径：

第一阶段：前置准备（在公有云中激活资源）

在云端，所有的安全行为和数据可见性首先依赖于“用户”向“销售/服务资源”的转化。

1. 用户同步：通过云端Security Console（安全控制台）创建员工，或直接通过企业统一身份认证（如 OCI IAM、Azure AD）自动同步。
2. 激活为销售/服务资源：
   • 导航至：Navigator > Resource Directory（资源目录）。
   • 将这些云用户添加为资源（Resource），并将其编入对应的Resource Organization Hierarchy（资源组织层级架构）中。
   • 注：云端层级保存后会实时计算，决定了后续“主管看下属数据”的安全逻辑。

第二阶段：用户与角色管理（包含 Abstract Role 与 Job Role）

导航至Tools（工具） > Security Console（安全控制台）。在创建或编辑用户时，必须采用“抽象角色 + 工作角色”的组合拳配置，否则用户登录后将无法看到主页或无法使用基础员工功能。

根据岗位职责，为用户并排勾选并分配以下两类角色：

1. 必须分配的抽象角色（Abstract Roles - 决定系统基础身份）

• Employee (员工)：所有正式员工必配。赋予访问系统主页、个人中心、提交费用报销以及作为销售资源的底层系统访问权。
• Line Manager (直线经理)：所有管理层必配（如销售主管）。赋予管理下属、审批下属提交的商机、线索或请假单的公共管理特权。
• Contingent Worker (临时人员)：如果呼叫中心客服或销售是外包人员，用此角色代替 Employee 角色。

2. 对应的业务工作角色（Job Roles - 决定业务操作职能）

备注：

市场营销？？？？

第三阶段：云端数据授权（Data Access - 领地、队列与团队）

在 CRM 云中，数据授权完全脱离了财务/供应链那种在表格里手工选 BU 的静态模式，而是由云端的引擎自动进行动态计算：

1. 销售系统安全：领地与层级（Territories & Hierarchy）

• 领地自动分派：在云端配置Territory Management，设定行业、地理位置、产品或客户规模规则。云端的Assignment Engine（分派引擎）会根据规则，自动把客户和商机划归到对应领地销售人员的账下。

备注：

不适用线索？？

• 经理层级穿透（Rollup Security）：基于第一阶段建立的资源组织层级，系统底层内置了穿透规则。拥有 Sales Manager 职能加 Line Manager 身份的主管，能跨商机、跨客户直接查看并修改其所有下属的数据。

2. 服务系统安全：队列与可见性（Queues & Access）

• 针对客户服务（Service Cloud），权限边界是通过Service Queue（服务队列）来管理的。
• 将客服人员分配到特定的队列（例如“VIP大客户队列”）。客服人员登录后，只能看到和处理属于自己所在队列的 Service Requests（服务工单），实现数据隔离。

3. 跨模块全景：团队共享（Account / Opportunity Teams）

• 销售人员可以在前端界面上，将其他同事手动拉入某个客户或商机的Team（团队）中，并直接赋予其Read Only (只读)或Read and Write (读写)权限，该授权实时生效。

第四阶段：高级扩展安全（云端专属的无代码/低代码安全定制）

如果需要针对特定企业个性化场景定制安全性（例如：隐藏特定敏感字段、根据条件限制商机访问），可在云端通过沙箱和配置工具实现：

1. 激活沙箱（Sandbox）：进入Manage Sandboxes，创建一个包含 Application Composer 工具的隔离沙箱。
2. 配置字段/对象级安全：进入Application Composer，找到对应的对象（如 Opportunity），在Security菜单下通过直观的矩阵式复选框界面，针对自定义角色直接勾选其是否拥有 Create（创建）、Read（读取）、Update（更新）或 Delete（删除）权限。
3. 编写条件安全逻辑（Groovy 脚本）：如需实现“只有当商机金额 > 5,000,000 时，才允许特定合规角色查看”这种高级需求，可以直接在安全性选项中编写一两行简易的 Groovy 表达式。
4. 发布沙箱：测试无误后发布沙箱，安全规则瞬间应用到全云端生产环境。

💡 实施专家闭坑与加速指南

• 启用“角色自动配置规则”（Autoprovisioning）：为了防止后续大批量导入用户时遗漏抽象角色，您可以在系统里配置一条全局规则：“只要系统新建了类型为 Employee 的用户，系统自动为其绑定 Employee 抽象角色”。这样后续实施时您只需专心分配 Job Role 即可。
• 善用“复制角色”而非重头创建：云端安全性策略极其庞大。如果标准 Sales Representative 不完全满足需求，请务必在 Security Console 中通过Copy Role (复制角色)机制，在其副本上进行裁剪，千万不要从头开始创建空白角色。

通过“身份（Abstract）+ 职能（Job）+ 动态分派（Data）”的完整配置，您的 Oracle Fusion Cloud CRM 安全系统即可安全、合规地投入生产运行。

接下来，为了让您的云端安全实施更加自动化，我们可以深入探讨：

• 如何配置Autoprovisioning 规则来实现 Employee 角色的自动发放？
• 如何配置云端的全渠道自动分派规则 (Omnichannel Routing)以保障工单流转安全？

市场营销内置Job Role

Oracle Fusion Cloud Applications Suite UX/CRM为市场营销内置了什么job角色

在 Oracle Fusion Cloud Applications Suite（基于新一代 UX 界面设计与融合的 CRM/Sales & Service 架构）中，系统为市场营销（Marketing）与线索管理内置了多个标准工作角色（Seeded Job Roles）。 [1]

以下是为市场营销业务内置的核心 Job 角色：

核心营销管理角色

• Corporate Marketing Manager（企业市场经理）：负责全局市场战略、整体预算管理、宏观市场活动规划以及跨团队的营销协同。 [1]
• Marketing Manager（市场经理）：负责营销信息、客户细分（Segmentation）、沟通渠道以及日常营销活动的具体发布与执行。 []
• Marketing VP（市场副总裁）、Chief Marketing Officer（首席营销官）：虽然属于高级别行政称谓，但系统内置了对应的高级分析、审批与仪表盘审阅权限（如高管看板）。

细分与自动化核心职责（Duty Roles 派生）

上述营销经理角色在系统底层直接集成了以下核心的职责角色（Duty Roles），使其天然具备以下完整功能：

• Marketing Automation Management：市场营销自动化管理。
• Marketing Segment Management / Usage：营销客户细分管理与应用。
• Marketing Content Creation / Publishing：营销内容创建、审批与多渠道发布。 []

营销与销售协同角色（线索与客户数据）

• Marketing Lead Administrator（营销线索管理员）：专门负责管理从营销活动中捕获的原始线索、配置线索评分（Lead Scoring）规则，并确保线索向销售阶段的高效流转。
• Customer Data Steward（客户数据管家）：在 CRM 营销中至关重要，负责清理营销数据库中的重复数据，确保群发邮件和营销触达的准确性。 [1]

💡 核心内置角色与主要权限对照表

若您目前正处于系统实施阶段，建议您复制这些内置角色并创建自定义角色（Custom Roles）进行微调（如修改为 XX_MARKETING_MANAGER_JOB），这样可以有效避免 Oracle 季度补丁更新时覆盖标准权限，同时又能完美继承其标准 UX 界面布局。 [1, 2]

系统也预留了与Oracle Unity CDP（客户数据平台）和Responsys/Eloqua营销自动化套件的标准集成接口权限。 [1]

您是否需要进一步了解如何通过安全控制台（Security Console）将这些内置营销角色分配给具体员工，或者需要了解具体的线索流转审批流（Lead Flow）配置？

有比 Marketing Manager（市场经理）更低职级的JOB 角色吗

是的，系统内置了比 Marketing Manager 职级更低（偏向基层执行、分析或基础操作）的内置 Job 角色。 [1]

在 Oracle Fusion Cloud Applications Suite 的权限架构中，角色的高低并不完全等同于行政职级，而是体现在对敏感数据的访问范围（Data Scope）以及是否具备审批/发布权限（Functional Privileges）上。

以下是系统中比标准市场经理职级更低的内置营销角色及基层替代方案：

1. 标准内置的低职级/基层 Job 角色

• Marketing Analyst（市场分析师）
  • 唯一标识码：MKT_MARKETING_ANALYST_JOB 或 ORA_ZCM_MARKETING_ANALYST_JOB
  • 定位：这是最典型的基层营销角色。
  • 权限差异：他主要负责查看营销数据、跑报表（BI 报表和仪表盘）、监控营销活动的效果。他不具备最终的营销预算审批权、宏观策略修改权或对大型市场活动的直接发布（Publish）权。 [1]
• Marketing Operations Specialist（市场运营专员）
  • 定位：类似于助理或执行层。
  • 权限差异：侧重于具体的系统内事务操作，例如根据既定模板上传邮件内容、录入联系人清单、或者核对销售线索。他只能在经理规划好的框架（Campaign 框架）内做局部编辑，不具备战略配置权限。

2. 通过“抽象角色”或“业务权限”降级（更细粒度的控制）

如果您希望配置一个类似“市场实习生”或“基础文案专员”的角色，在 Oracle Fusion 中通常会采用以下两种更符合 UX/CRM 规范的做法：

• Marketing Approver (MKT_MARKETING_APPROVER_ABSTRACT) - 剥离此角色：
  系统中部分发布、审批权限是作为“抽象角色”（Abstract Role）单独存在的。如果一个新员工只有 Job 角色，而没有被赋予对应的审批抽象角色，他在系统中的实际职级和系统操作权限就是最低的，所有建立的活动、线索全部需要上报审批。 [1]
• 分配只读/局部编辑的 Duty Roles（职责角色）：
  在自定义角色时，不直接复制 Manager，而是仅把底层最基础的 Duty Role 赋给员工，例如只赋予 Marketing Work Area View Duty（只能看到市场工作区，不能改）或者 Marketing Campaign View Duty（营销活动只读查看）。 [1, 2]

📌 营销岗位系统权限级别对比

您是否需要了解如何通过系统的Security Console（安全控制台）针对这些基层角色进行数据维度的限制（例如：让基层专员只能看到自己负责的区域或产品线的营销线索，而看不到全公司的数据）？

线索与领地与层级分派规则

在以前的聊天中，关于 Oracle Fusion Cloud Applications Suite ，有下面的内容： 销售系统安全：领地与层级（Territories & Hierarchy） • 领地自动分派：在云端配置 Territory Management，设定行业、地理位置、产品或客户规模规则。云端的 Assignment Engine（分派引擎） 会根据规则，自动把客户和商机划归到对应领地销售人员的账下。 备注： 不使用线索？？ • 经理层级穿透（Rollup Security）：基于第一阶段建立的资源组织层级，系统底层内置了穿透规则。拥有 Sales Manager 职能加 Line Manager 身份的主管，能跨商机、跨客户直接查看并修改其所有下属的数据。 这里只提到了商机和客户，不使用线索吗？

系统完全支持在线索（Leads）阶段使用领地与层级分派规则。[1, 2, 3]

之前的内容重点提及“客户和商机”，是因为在销售管理中它们是核心核心实体，而线索（Leads）作为整个销售漏斗的最前端，同样完全内置在云端的分派引擎（Assignment Engine）和经理穿透规则（Rollup Security）中。 [1, 2]

Oracle Fusion 对线索的“领地分派”与“安全性控制”有极具特色的底层逻辑，具体如下：

1. 线索的领地自动分派（Lead Territory Assignment）

系统完全可以使用 Territory Management 来自动化流转线索。当一条原始线索被捕获（如来自营销系统或官网注册），分派引擎会进行以下双层匹配： [1, 2]

• 领地匹配（Territory Assignment）：根据线索中的行业、国家/省份、公司规模等维度，匹配出这条线索属于哪个“销售领地”。 [1, 2]
• 资源规则匹配（Resource Rules）：特别注意，Oracle 的底层逻辑中，领地分派将线索划归给某个“领地”，而具体的销售人员（Owner）则是通过规则引擎（Assignment Rules）进一步精准指派的。例如：匹配到“华东区大客户领地”后，再根据工作量规则或轮询（Round-Robin）规则，具体分给该领地下的某位具体的销售专员。 [1]

2. 经理层级穿透（Rollup Security）完全适用于线索

在安全控制和数据可见性上，线索与商机的规则完全一致。 [1]

• 当一个基层销售人员被系统分派为某条线索的 Owner（或销售团队成员）时，在资源层级（Resource Hierarchy）上处于其上方的 Sales Manager 和 Line Manager，天然获得该线索的穿透查看与修改权限。 [1]
• 经理可以在其专有的营销线索仪表盘（Sales Lead Dashboard）中，直接穿透监控下属所有正在跟进、跟进超时或待转化的线索数据。

💡 为什么日常讨论中经常给人“不使用线索”的错觉？

在实际的企业 CRM 落地实施中，由于以下业务差异，线索的分派逻辑经常会被“区别对待”：

1. 企业直销模式（B2B 大客户模式）：在这类销售模式中，很多企业选择在营销系统（如 Eloqua）中完成线索的打分和初筛。当线索推送到 CRM 时，客户在系统中已经存在。因此企业往往直接使用客户领地（Account Territory）作为基准，即：“这个客户是谁的领地，推过来的新线索就自动归谁”。这就导致表面上看起来直接使用了客户规则。
2. 线索特有的分派维度：线索在转化为商机前，数据往往是不全的（例如只有个邮箱和电话，没有具体的“产品线”和准确的“客户规模”）。因此，线索通常更多地依赖于基础地理位置（如城市）或线索来源（如展会、官网）

进行分配，而进入商机阶段后才会使用复杂的矩阵式领地规则。

🛠️ 实施配置避坑提示

如果您正在配置系统的线索分派，需要注意系统中存在两个不同的配置入口：

• 商机与客户：主要在 Manage Territories 中配置领地覆盖范围。
• 线索：需要额外在 Manage Sales Lead Assignment Objects 和系统配置文件（Profile Options）中，勾选同时启用规则与领地分派（Enable Lead Assignment using Rules and Territories），否则系统只会跑纯规则指派而忽略领地。 [1, 2, 3]

您是否正在为企业规划线索转化（Lead Conversion）的业务流程？我可以为您梳理“线索转商机”时，领地和销售团队如何无缝继承的底层逻辑。