针对你遇到的问题——用LastModifiedByFlow Yes/No列防止无限循环，但不知道何时将其重置为false以允许用户后续修改触发流，这里有一个完整的可落地解决方案：

核心思路 #

我们需要构建一个逻辑闭环，同时满足三个要求：

1. 仅在用户修改列表项（且LastModifiedByFlow为false）时触发流运行
2. 流自身修改列表项时，不会触发新的流实例
3. 流完成业务逻辑后，自动将LastModifiedByFlow重置为false，不引发循环

具体步骤 #

1. 调整触发器的触发条件 #

修改你的When an item is created or modified触发器的触发条件为：

@and(equals(triggerBody()?['LastModifiedByFlow'], false), not(contains(triggerBody()?['Changed Fields'], 'LastModifiedByFlow')))

这个条件的作用拆解：

• 第一个判断：仅当LastModifiedByFlow为false时（对应用户修改的场景）
• 第二个判断：本次修改的字段不包含LastModifiedByFlow（直接排除流自身修改该列的场景）
  只有同时满足这两个条件，流才会启动。

2. 更新流的执行逻辑 #

调整后的完整流结构如下：

1. 触发器：When an item is created or modified（已设置上述触发条件）
2. 创建你需要的业务变量
3. 执行第一个Update item动作：
   • 正常更新你的业务字段（比如计算值、状态标签等）
   • 同时将LastModifiedByFlow设为true

   这一步的修改会触发SharePoint的修改事件，但因为我们修改了LastModifiedByFlow，Changed Fields数组会包含该字段，触发条件不满足，不会启动新的流，直接避免了循环。

4. （可选）执行其他业务逻辑（比如发送通知、调用外部API等）
5. 执行第二个Update item动作：
   • 仅将LastModifiedByFlow设为false

   这一步修改LastModifiedByFlow列，Changed Fields会包含该字段，触发条件不满足，不会触发新的流实例。但此时列值已重置为false，用户下次修改其他业务字段时，流会正常触发。

方案有效性说明 #

• 用户修改项时：修改的是业务字段，LastModifiedByFlow为false，且Changed Fields不包含该列，满足触发条件，流正常启动。
• 流修改LastModifiedByFlow时：Changed Fields包含该列，触发条件直接过滤掉这个修改事件，不会引发无限循环。
• 重置列值后：用户后续的修改操作能再次满足触发条件，流可以正常响应。

额外注意事项 #

• 确保LastModifiedByFlow列的内部名称正确（可通过SharePoint列表设置的字段详情页查看，触发条件中必须使用内部名称）
• 如果在Update item中同时修改多个字段，只要其中包含LastModifiedByFlow，Changed Fields就会包含该列，触发条件会自动过滤这个修改事件

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