使用生命周期工作流，能够创建可基于加入者、调动者或离职者场景触发的工作流。 虽然生命周期工作流提供了多个内置任务，用于自动实现用户整个生命周期内的常见场景，但最终可能会达到这些内置任务的上限。 借助扩展性功能，可以利用自定义任务扩展的概念作为工作流的一部分调用外部系统。 例如，当用户加入组织时，你可以拥有具有分配 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：将新创建的自定义任务扩展添加到新工作流，或将信息更新到现有工作流。