Hi Mark，

取决于您是否要通过SDK/编码或通过关键用户工具来执行此操作。 对于SDK，必须记录批准流程，然后实施您的技术资源。

通过KUT，您可以将微调，扩展字段，规则编辑器，代码列表限制，页面布局（如果需要）和工作流程规则结合起来使用。

1。 在批准者1-3的微调中创建新的参与者角色定义。 那将是3个条目。 您还可以将它们添加为参与方，以便您对参与方进行微调。 如果每个帐户都附有相同的批准人，则可以在设置主数据后设置自动确定。 如果对于每个机会都是唯一的，则用户必须通过在机会中销售团队方面选择员工来手动设置每个批准者。

2。 创建3-6个扩展名字段。 如果可以通过状态或UI上已有字段中的某些其他条件触发批准工作流程的条件，则只需3个扩展字段。 您将使用每个批准者的三个字段来选择一个用于批准的下拉选项（已批准，已拒绝，需要修订）。 您可以使用规则编辑器使该字段成为必填字段，而所有其他字段仅在满足条件后直到设置批准1才显示。 当满足其批准条件时，您将对每个批准字段执行此操作。 您还可以使用页面布局来确保只有批准者可以打开要编辑的字段，而那些仅请求批准的人只能看到显示内容。 再次使用规则编辑器，以确保在设置了批准1的条件时，仅打开用于第一次批准的扩展名字段进行编辑。

3。 如果您的用户已经可用的字段无法满足您的批准条件，则可能需要再触发3个字段来批准阶段。 用户可以手动设置（可以使用规则编辑器来确保设置），也可以通过工作流通过条件进行设置。 一旦设置了"需要批准的扩展名"字段1，这将成为由定制参与方批准人1设置"批准结果1-"已拒绝，已修订，已批准"字段的条件。

4。 您可以使用工作流，根据设置的第3步中已经可用或自定义字段中的条件，将电子邮件发送给每个批准者。 在确定接收者的情况下，您可以根据哪一步选择批准者之一。 步骤3所需批准将选择接收方批准人3。因此，您将使用3种工作流程，可能是3种不同的形式。

5。 最后，您还可以编写代码列表限制，以阻止将机会设置为"获胜/失败"。 根据您何时可以设置某种状态的规则，这可能需要多个代码列表限制。

关于，
格雷森