Microsoft Bookings预约创建人记录：Graph无createdBy字段的可靠方案

1. Graph/Bookings是否存在可返回创建者的API或字段 #

目前没有遗漏的官方API或字段可以直接返回bookingAppointment的创建者UPN/objectId。不管是Microsoft Graph的v1.0还是beta版本，bookingAppointment资源仅提供createdDateTime（创建时间）和selfServiceAppointmentId（区分客户自助创建）两个相关字段，完全不包含创建者的身份标识信息。

2. 可靠的捕获方案 #

如果必须获取员工在Bookings原生UI创建预约的身份信息，可采用以下几种可靠方案：

方案一：利用Microsoft 365审核日志 #

• 先在Microsoft 365合规中心开启Bookings的审核日志功能（路径：合规中心 > 审核 > 审核日志搜索）。
• 当Power Automate触发“新增预约”事件后，调用Microsoft Graph的GET /auditLogs/unifiedAuditLogs接口，设置过滤条件：
  • operationName等于Create booking appointment
  • resourceId等于新增预约的ID
  • createdDateTime范围设为预约createdDateTime前后5分钟内
• 从返回的审核事件中提取actor.userPrincipalName和actor.objectId，即为创建预约的员工标识。
• 注意：审核日志存在最多15分钟的延迟，流中需添加等待步骤或重试逻辑确保能查询到对应事件。

方案二：自定义预约属性+Power Automate填充 #

• 在Bookings的预约表单中添加一个自定义文本字段（如“创建者UPN”），设置为内部可见或隐藏状态。
• 创建Power Automate流，触发条件为“当Bookings预约被创建或更新”，若流以触发用户身份运行，可直接获取当前用户的UPN/objectId并填充到自定义字段中。
• 局限性：若流使用服务账号运行，此方案无法直接获取创建者信息，需调整流的运行权限为“使用触发流的用户身份运行”。

方案三：改造预约创建流程 #

• 引导员工通过自定义入口（如Microsoft Forms表单、Teams机器人）创建预约，而非直接使用Bookings原生UI。在这些入口中可直接捕获当前用户的UPN/objectId，同时调用Graph API创建Bookings预约，并将创建者信息存入自定义字段或关联的数据源。
• 优势：数据获取直接可靠，无需依赖审核日志延迟；劣势：需要员工调整原有操作习惯。

内容的提问来源于stack exchange，提问作者Thiago Luan