Meta example: a message opens a multi-screen Flow for product preferences and selection. This illustrates the customer experience, not YCloud's Flow editor.
了解核心构成
Flow 归属于某个 WABA。它的定义描述了屏幕、输入字段、导航以及完成行为。 某些 Flow 使用发送消息时提供的数据。其他 Flow 则需要数据端点在交互过程中检索最新信息或处理选择。 例如，预约 Flow 可能会收集服务项目、首选日期和联系方式。如果它必须显示实时可用性，端点和您的预约系统必须协同处理这些数据。 Meta 提供了关于屏幕设计、端点集成、加密、测试和健康监控的 Flows 指南。Flow 与其邀请消息是独立的
您发送用于打开 Flow 的消息：- 在开放的服务窗口内使用受支持的交互式 Flow 消息。
- 在需要模板时，使用带有 Flow 按钮的已获批模板。
创建、测试与发布
YCloud 的 Flows API 指南涵盖了创建、检索、更新、预览、发布和弃用 Flow 的全流程。 在验证结构和测试客户体验旅程时，请保持内容为草稿状态。发布是一个生命周期分界点；在修改线上体验时请规划替代版本，并在尝试就地更改前检查当前的 API 规则。 测试：- 必填字段与无效输入。
- 返回导航与中途放弃。
- 端点错误或不可用的预约时段。
- 重复提交。
- 完成提示消息及后续业务操作。
示例：预约申请
一个实用的初始版本包含三个屏幕：
如果仅收集首选时间供人工客服稍后确认，请使用静态 Flow。如果可选项目必须随实时库存变化，请使用由端点驱动的 Flow。不要将静态列表显示为有保证的可用性。
编写与实际结果相符的完成屏幕文案。当仍需工作人员确认时，“已收到申请”比较合适；而“预约已确认”则需要您的预约系统已成功保留该时段。
区分不同的标识符
- Flow ID 用于标识可复用的表单。
- 消息 ID 用于标识单次邀请及其发送记录。
- Flow 令牌（token）（由您的集成提供）将交互与您的业务上下文关联起来。
- 您的 预约或申请 ID 用于标识最终生成的业务记录。
在正确的阶段排查问题
这些检查有助于防止将发送问题与表单或预约问题混淆。
谨慎处理数据
仅收集必要的信息。说明其用途并提供相关的隐私信息。 对于由端点驱动的 Flow，请遵循 Meta 的加密和端点要求。切勿在 Flow JSON 和公开预览中包含机密信息。测试时请使用合成数据。 在正确的客户上下文中保存并处理提交的数据。设计重复提交处理机制，避免重复提交导致产生两次预约或重复扣费。在 YCloud 中继续
请将 Flow 发送、表单提交以及业务成效作为独立的指标分别进行衡量。常见问题
每个 Flow 都需要后端端点吗？
每个 Flow 都需要后端端点吗？
不需要。静态 Flow 可以在每个屏幕不实时拉取数据的情况下收集选项或信息。当选项或验证依赖于当前系统（例如可用的预约时段）时，才需要使用端点。您仍需确定提交后的回复内容发送到何处以及由谁进行处理。
客户提交了表单，我可以立即发送预约确认消息吗？
客户提交了表单，我可以立即发送预约确认消息吗？
仅在您的预约系统已成功锁定该时段时才可以。已填写的表单可能只是一个申请，并不等同于已确认的预约。请使用请求 ID、验证可用性、处理重复提交，并确保确认消息的措辞与实际处理结果一致。
我可以将同一个 Flow 同时用于客服回复和主动触达吗？
我可以将同一个 Flow 同时用于客服回复和主动触达吗？
表单本身与发送表单的邀请消息是分开的。在客服服务时间窗口内，可以使用符合条件的交互式 Flow 消息；在需要使用模板时，可以使用带有 Flow 按钮的已获批模板。邀请消息的实际用途决定了其消息类别；附加表单并不会将营销类消息变成实用类消息。