生命周期工作流自定义任务扩展
使用生命周期工作流，能够创建可基于加入者、调动者或离职者场景触发的工作流。 虽然生命周期工作流提供了多个内置任务，用于自动实现用户整个生命周期内的常见场景，但最终可能会达到这些内置任务的上限。 借助扩展性功能，你能够利用自定义任务扩展的概念，将外部系统作为工作流的一部分进行调用。 例如，当用户加入组织时，可以创建一个带自定义任务扩展的工作流以分配 Teams 号码，或者创建一个单独的工作流，以在用户离开时授予经理对电子邮件帐户的访问权限。 借助扩展性功能，生命周期工作流目前支持创建自定义任务扩展，以调用 Azure 逻辑应用。
逻辑应用先决条件
要将 Azure 逻辑应用与自定义任务扩展链接，必须满足以下先决条件：
- Azure 订阅
- 资源组
- 创建新的基于消耗的逻辑应用的权限，或对现有基于消耗的逻辑应用的访问权限
在逻辑应用本身或更高范围（如资源组、订阅或管理组）上需要以下 Azure 角色分配之一：
- 逻辑应用参与者
- 参与者
- 所有者
注意
逻辑应用操作员角色权限不足。
自定义任务扩展部署方案
创建自定义任务扩展时，它与生命周期工作流交互的方案可以是以下两种方式之一：
- 启动并继续 - Azure 逻辑应用已启动，会立即继续执行后续任务，Azure 逻辑应用没有预期响应。 如果生命周期工作流不需要 Azure 逻辑应用的任何反馈（包括状态），则此方案最适合。 如果逻辑应用已成功启动，则生命周期工作流任务被视为成功。
- 启动并等待 - Azure 逻辑应用启动后，将等待逻辑应用的响应才能执行后续任务。 可以输入自定义任务扩展等待 Azure 逻辑应用响应应该持续的时间。 如果在已定义的持续时间窗口中未收到任何响应，则任务将被视为失败。
注意
响应并不一定由逻辑应用提供，如果逻辑应用仅充当中介，则第三方系统也能够做出响应。 要了解有关此项的详细信息，请参阅：taskProcessingResult: resume。
响应授权
在创建等待逻辑应用响应的自定义任务扩展时，可以定义哪些应用程序可以发送响应。
可以通过以下方式之一对响应进行授权：
- 系统分配的托管标识（默认）- 使用此选项时，可启用并利用逻辑应用系统分配的托管标识。 有关详细信息，请查看：在 Azure 逻辑应用中使用托管标识验证对 Azure 资源的访问
- 无授权 - 使用此选项时，不会授予任何授权，因此必须单独分配应用程序权限 (LifecycleWorkflows.ReadWrite.All) 或角色分配（生命周期工作流管理员）。 如果应用程序正在响应，则不建议使用此选项，因为它不遵循最低特权原则。 如果仅代表用户提供相应（LifecycleWorkflows.ReadWrite.All 委派权限和生命周期工作流管理员角色分配），则也可能使用此选项
- 现有应用程序 - 通过此选项，你可以选择要响应的现有应用程序。 这可以是常规应用程序，也可以是系统或用户分配的托管标识。 有关托管标识类型的详细信息，请参阅：托管标识类型。
自定义任务扩展与 Azure 逻辑应用集成的概要步骤
Azure 逻辑应用集成的概要步骤如下：
注意
通过 Microsoft Entra 管理中心创建自定义任务扩展和逻辑应用的操作会自动执行大部分步骤。 有关以这种方式创建自定义任务扩展的指南，请参阅：基于自定义任务扩展触发逻辑应用。
- 创建基于使用量的 Azure 逻辑应用：基于使用量的 Azure 逻辑应用，用于从自定义任务扩展中调用。
- 配置 Azure 逻辑应用，使其与生命周期工作流兼容：配置基于使用量的 Azure 逻辑应用，使其可与自定义任务扩展结合使用。 有关详细信息，请参阅配置生命周期工作流使用的逻辑应用
- 在 Azure 逻辑应用中生成自定义业务逻辑：使用逻辑应用设计器在 Azure 逻辑应用中设置业务逻辑。
- 创建生命周期工作流 customTaskExtension，其中包含有关 Azure 逻辑应用的必要信息：创建引用已配置的 Azure 逻辑应用的自定义任务扩展。
- 创建具有“运行自定义任务扩展”任务的生命周期工作流或更新现有工作流，引用创建的 customTaskExtension：将新创建的自定义任务扩展添加到新工作流，或将信息更新到现有工作流。