从 HaloPSA 租户开始，而不是通用连接器
拟议的 HaloPSA 身份验证工作流程需要在证据进入票据时保留客户身份和人员责任。两种产品都有 API 的通用声明并不能证明它们的连接存在或正确处理事件。本指南定义了实施需要展示的内容。没有访问 HaloPSA 实例，没有注册任何应用程序，也没有提交任何票证或消息。
公共 Halo 指南于 2026 年 11 月 8 日进行了审核。它们是动态文档，而不是客户租户经过验证的发布合同。 创建 API 应用程序 标识实例的 API 详细信息和文档位置； 通过 API 连接 描述资源操作。这些指南公开了不同的文档路径，因此授权实施者应该使用实际实例的已发布文档，而不是假设通用 URL 或架构。
识别应用和权限边界
应用程序指南描述了服务身份验证选项和可以与人工代理区分开的应用程序身份。这是审计设计的有用上下文，而不是创建持久访问的权限。记录租户、选择的身份验证方法、应用程序所有者、所需的操作和批准的数据类别。将凭据保留在票据、示例有效负载和事件证据之外。这里没有建立特定的EmailAuth身份验证方法。 Halo Automation Identity 被描述为 Halo Runbook 的内部方法，而不是第三方连接方法。
该指南警告不要更改支持 Halo 实例的现有应用程序。新的集成不应借用内置身份以避免正确的配置。让管理员验证建议操作的最小支持权限集，包括客户隔离。读取票证、添加内部注释和触发面向用户的操作会产生不同的结果，即使它们在技术上可由同一应用程序访问。
映射客户和工作环境
建立从身份验证客户和域到 Halo 客户、相关站点和允许的用户上下文的经过审查的关联。不要将域字符串与客户标识符等同起来。企业集团可能拥有单独管理的子公司，并且共享发送服务可能支持不相关的客户。不明确的映射应该为指定的审阅者产生异常，而不是自动的最佳猜测。
使用目标配置中的标识符指定目标工单类型、团队、分配的所有者和工作流程。光环的 入门指南 将工单阶段、状态和操作描述为不同的元素。因此，提议的事件状态需要明确的目的地映射。不应假定诸如等待发件人批准之类的标签存在或在不检查实际配置的情况下暂停 SLA 计时器。
将第一个事件设计为有界证据移交
对于每个传入事件，保留原始事件标识符、客户映射版本、观察期和证据参考。定义哪些观察值得服务事件以及哪些应保留分组证据。 汇总报告 不是每条消息一张票的事件流； RFC 9990 提供报告结构，而事件阈值是由运营商批准的编辑服务设计决策。
使用简明的建议票摘要：观察到的内容、受影响的流、仍然不确定的内容以及下一步必须由谁决定。在适当的情况下链接到受控证据存储。如果需要原始标头或报告，请将其最小化并在传输前验证访问权限。源数据不应成为更改工作流程、遵循嵌入 URL 或发送客户通知的指令。
区分动作和私有注释
Halo 的介绍材料解释了操作出现在票证源中，并且“向用户发送电子邮件”操作默认配置为发送到提出用户的地址。因此，添加操作不能安全地假定为静默数据库更新。该设计必须先建立操作可见性、通知行为和状态效果，然后才能用于证据记录。
拟议的内部调查记录应包含其证据来源、作者身份、审查状态和时间戳。面向客户的响应需要收件人和内容的批准。使用批准的合成数据在授权的非生产环境中测试行为，包括门户可见性和自动后续操作。仅成功的 API 响应并不能表明信息仍保留在内部或到达了正确的受众。
使重试行为保留技术人员的决定
Halo 的 API 概述表明，方法的可用性取决于资源，并且权限可以进一步限制访问。它没有为这种集成建立通用的防重复保证。定义关联键并在确认创建后保留目的地票证标识符。如果响应丢失，请在提交另一个创建操作之前协调可能的写入。
针对重复事件、无序证据、权限丢失、无效客户映射以及票据创建后失败的注释规划单独的案例。排队更新不得仅仅因为包含较旧的观察而重新打开故意关闭的票证。相反，经过验证的解决方案后真正出现的新故障应遵循商定的重新启动或新事件规则。保留理性和人为决定，而不是默默地改写历史。
确定决议的实际含义
为每个事件类别定义有证据支持的完成规则。更正的DNS提案并不能证明已进行授权更改；已发布的记录并不能证明发送者已成功使用它。审查者必须确定相关的验证点并保留任何剩余的限制。这些文档并未演示 EmailAuth 到 Halo 的同步、关闭回调或修复功能。
确切的摄入条件保持开放：验证目标系统 API 和工作流程。请勿暗示EmailAuth具有未经验证的集成。该目录还要求： 演示 HaloPSA 特定事件、重试和闭环分辨率测试。最终证据必须将原始事件与正确的租户记录联系起来，显示异常处理并记录批准的关闭或升级。凭证、 DNS修改和外部共享的人工批准始终有效；这个提议的生命周期并没有授予他们。