Workflowが期待通りにトリガーされないのは、チャネルの互換性、オーディエンスルール、スケジューリング、Messenger設定との競合などの設定問題が原因かもしれません。これらの問題のトラブルシューティング方法はこちら。

workflowが会話で発火した時刻は以下から確認できます：

はい、メール、電話、名前などの顧客データや、Intercomで追跡しているカスタム属性を収集する再利用可能なworkflowsを作成できます。

これは現在Workflowsでは不可能ですが、役立つ場合は機能リクエストとして提出できます！

ユーザーがページを訪れたときにウェルカムボットがメッセージ全文とオプションを表示しないようにするには、別のworkflowトリガーを使う必要があります。Workflowが積極的にポップアップする「customer visits a page」トリガーの代わりに、「Customer opens a new conversation in the Messenger」トリガーを使ってください。これにより、ウェルカムメッセージはユーザーがMessengerで会話を開始したときのみ表示されます。

顧客はMessengerランチャーを直接クリックして、意図したフロー外で会話を開始することで、アウトバウンドメッセージworkflowsを回避することがあります。

これに対処する主な方法は2つあります：

Intercomでアウトバウンドボット（Workflows）にアクセスするには、以下の要件を満たしている必要があります：

はい、Collect dataステップで顧客からファイルをいくつかの方法で収集できます：

はい、Workflowsに「Tag conversation」ステップを追加することで、会話に自動的にタグを付けることができます。Workflowsの任意の場所でAdd stepをクリックし、Tag conversationを選択してください。これは今後の会話にのみ適用され、遡っては機能しません。

Workflowsで「if」条件を作成し優先順位をつけるには、より多くの条件付きbranchesを追加します。branchesの優先順位は上から下に適用されます。

営業時間外に顧客にメッセージを送信するには（例えば、返信予定時間を知らせる場合）、トリガー設定でスケジュールするのではなく、branch条件を使ってWorkflowsを設定してください。branchesはリアルタイムで評価され、時間ベースのロジックにより信頼性があります。

有効化すると、設定した営業時間外に到着したトリガーに一致する新しい会話は自動的に設定したメッセージを受け取ります。

Workflowsがメール会話のみにトリガーされるようにするには、トリガー設定でチャネル選択を制限する必要があります。チャネルが明示的に有効になっていない場合、そのチャネルの会話はWorkflowsをトリガーしません。

有効化すると、オーディエンスルールに一致するメール会話のみがこのWorkflowsをトリガーします。他のチャネルの会話は影響を受けません。

現時点では、Workflowsのオーディエンスフィルター設定で選択できるのはPeopleまたはCompanyタグのみです。Conversationタグはこの目的には使用できません。

Workflowsに外部コンテンツを追加するには、「Send an app」ステップを追加し、Content Showcaseアプリを選択します。

はい、Workflowsに「Message contains XYZ」条件を追加すると、本文だけでなくメールの件名も検索します。別に「Email subject contains XYX」条件を使っていても、「Message contains」を使うと件名も含まれます。

これはWorkflowsで有効にしたチャネルによります。Web、iOS、Android、Facebook、Instagram、EmailでのWorkflowsメッセージ送信には料金はかかりません。

ただし、SMSやWhatsAppをWorkflowsチャネルに選択している場合、これらのチャネルで送信されたメッセージにはそれぞれの料金がかかります。

これを実現するには、2つのWorkflowsを作成する必要があります。

この設定により、Resolved/ClosedのTicketに対する顧客の返信は自動的に「In progress」に移動します。

「Teammate changes the conversation team assignment」トリガーを使ったworkflowを設定すると、会話がチームInboxに割り当てられたときに特定のチームメイトを自動的に割り当てられます。

トリガーの対象で「Team assigned is [X]」を選択します。

次に、Assignステップを使ってチームメイトに割り当てるworkflowパスを追加します。

本番環境でライブユーザーに影響を与えずに更新されたworkflowロジックをテストするには：

可能な場合は、ライブ会話に予期しない影響を与えないよう、まずステージング環境でテストしてください。

ライブユーザーに影響を与えずにメールworkflowをテストするには：

未テストの変更を直接ライブworkflowに加えるのは避け、まず複製してリスクを分離してください。

Finが属性を正しく検出しているか安全にテストするには：

はい。2つの方法があります：

Workflows Preview機能で作成されたプレビュー会話はInboxに表示され、実際の会話として扱われます。つまり、プレビューユーザーのアクティビティもworkflowのレポート指標に含まれます。テスト後にレポート数値が予想外に高い場合は、プレビューユーザーのアクティビティがカウントされているか確認してください。指標を正確に保つため、プレビューセッション後に送信数/エンゲージ数/完了数を見直すことを検討してください。

顧客が営業時間外に以前に閉じた会話を再開した場合、標準の営業時間外workflowは期待通りにトリガーされないことがあります。

これを確実に処理するには：

有効化後、顧客が閉じた会話を再開すると、Intercomは営業時間と照合し、設定された営業時間外であればメッセージを送信します。

顧客がクローズまたはスヌーズされた会話に返信すると、Intercomはワークフローの評価前にそれを再オープン（またはスヌーズ解除）します。Customer sends any message ワークフローが条件を実行する時点で、会話はすでにオープンしているため、Conversation status = Closed または Conversation status = Snoozed の条件は一致しません。これにより、このワークフローで会話状態属性は条件として実質的に使用できなくなります。

同じ再オープンの動作はスヌーズされた会話にも適用されます。顧客の返信により、ワークフロー評価の前に会話は自動的にスヌーズ解除されます。

ワークフロー目標は、ワークフローがトリガーされた後に発生したイベントのみをカウントし、送信前に発生したイベントは含みません。

いいえ、ワークフロー内のクイックリプライボタンの表示はカスタマイズできません。

いいえ、ワークフローはデータを外部のメールアドレスに直接送信できません。ワークフローは顧客データ（名前、メール、カスタム属性など）を収集し、会話を未割り当てのままにできますが、そのデータを外部メールアドレスに送信することはサポートされていません。外部にデータを転送する必要がある場合は、Data connectorを使用するか、webhook経由でサードパーティツールと連携してください。

いいえ、Messengerやワークフロー内でPINやIDの長さの入力検証はサポートされていません。特定の文字数や桁数の要件を強制する必要がある場合は、独自のバックエンドやData connectorを使って収集後に検証する必要があります。

特定の会話でWorkflowが機能しない場合は、ワークフローの対象設定が正しい参加者タイプ（Leads、Visitors、Users）にトリガーされるように設定されているか確認してください。問題解決のために対象設定を更新してください。また、設定ミスで正しい対象にトリガーされていない可能性もあります。例えば、ワークフローが「Users」のみを対象にしている場合、「Leads」を含むやり取りはトリガーされません。対象フィルターを「Leads」と「Users」の両方に調整するか、会話タイプがワークフロー設定に合っているか確認してください。

これは、サイトのContent Security Policy（CSP）がIntercomとの特定の接続をブロックしているために発生することがあり、Messengerの正常な動作に必要な接続を見直し、更新する必要があります。CSPとIntercomの使用に関する詳細はこちらの記事をご覧ください。

会話ごとに顧客向けのWorkflowトリガーは1つだけです。これを実現するには、「When customer sends their first message」の既存ワークフローを編集し、顧客の最初のメッセージを収集するステップを追加し、その後にフォローアップメッセージ「確認中です。お待ちください。」を送信するステップを追加してください。

日時属性は、顧客のタイムゾーンを確実に検証する方法がないためワークフローで使用できません。VPN利用やオフィス時間と異なる場所からのアクセスで不一致が生じる可能性があります。ワークスペースの営業時間との不整合を避けるため、日時属性はワークフローで使用できません。

いいえ。日付属性はワークフローステップで設定できません。これは現在の製品の制限です。会話データ設定などのワークフローアクションは日付属性タイプをサポートしていません。

日付属性を更新するには、REST APIを使用したData Connectorを利用する回避策があります。

ワークフローの「Conversation starter is Outbound message」オーディエンスルールは、ワークスペースのOutboundセクションからメッセージを送信する場合にのみ適用されます。Inboxで会話を作成する場合は、ワークフローのオーディエンスルールで個別メッセージには「Teammate sending a direct message」、一括メッセージには「Teammate sending to many customers」を使用してください。

メールがチケットに変換された場合にワークフローがトリガーされない場合は、ワークフロートリガー設定でチャネルに「Email」が選択されているか確認してください（これは会話が開始された元のチャネルです）。

電話から変換されたTicketsは、元の会話の「Phone call」チャネルを保持します。つまり、チャネル依存のワークフロートリガー（例：Teammate changes conversation state）は、作成時のチャネルを評価するため、これらのTicketsでは発火しません。

この制限は、Teammate changes conversation stateのようなチャネル依存トリガーに特に適用されます。電話発信のTicketsにCSAT調査を送信する場合、このトリガーは発火しません。

これを回避するには、代わりにチケットトリガーワークフロー（例：Teammate changes the state of a ticket）を使用し、関連するチケットタイプを対象に設定してください。このトリガーは元のチャネルに関係なく、チケット状態の変更を直接評価します。

または、When a phone call endsトリガーを使用して、電話および電話発信Ticketsの通話後アクションを自動化してください。チャネル依存トリガーとは異なり、通話がどのように終了したかに基づいて発火します。設定手順と例はAutomate actions when a phone call endsをご覧ください。

Show workflow untilセレクターは、繰り返しスケジュールやイベントベースのトリガーがない標準のWhen customer visits a page自動メッセージワークフローでのみ利用可能です。

ワークフローに繰り返しスケジュール（例：週次やカレンダー基準のスケジュール）がある場合、このオプションは意図的に非表示にされています。繰り返しスケジュールのメッセージは送信サイクルごとに1回表示されるため、Show workflow untilピッカーは自動的に無効になります。

これらは通話ライフサイクルの異なる時点で実行される2つの別々のトリガーです。

いいえ、チームメンバーが通話中に切断しただけの場合は発火しません。このトリガーは、顧客とすべての外部参加者が切断した通話の真の終了時に1回だけ発火します。チームメンバーが切断しても顧客がまだ通話中の場合、通話は継続中でトリガーは実行されません。

メッセージ送信、返信ボタンによるデータ収集、期待返信時間の表示などの顧客向けアクションは、ライブ通話トリガーを使用するワークフローでは利用できません。通話中は顧客が電話に出ており、チャットメッセージを読んでいないため、これらのステップは意図的に無効化されています。

ライブ通話トリガーは、通話者を妨げずに静かに実行されるバックグラウンドアクションのみをサポートします：会話のタグ付け、再割り当て、スヌーズ、ルール適用、内部メモ追加。ビルダーには「Phone Call workflows support a reduced set of actions」というバナーが表示されます。

はい、「When a phone call ends」は着信・発信の両方の通話に対応しており、通話方向に関係なくトリガーが発火します。通話終了方法で分岐する場合は、方向に応じた正しい属性を使用してください。

状態の完全なリストと例のWorkflowsについては、電話通話終了時の自動化アクションを参照してください。

これは予想される動作です。「電話通話終了時」トリガーは会話とTicketの両方に自動的に適用されます。電話通話がTicketに紐づいている場合、そのTicketにもトリガーが発動します。会話のみまたはTicketのみへの制限はできません。

Ticketと会話で異なる通話後のロジックが必要な場合は、Workflows内に条件ステップを追加して、会話かTicketのタイプで分岐させてください。

いいえ、通話中に電話通話をTicketに変換することはできません。Ticketへの変換オプションは通話終了後に会話ヘッダーでのみ利用可能になります。

電話通話から作成されたTicketに対してアクションを自動化するには、TicketトリガーWorkflowを使用してください。例えば、Ticketが作成されたときやチームメンバーがTicketの状態を変更したときなどです。これらはチームメンバーが終了した通話を手動でTicketに変換した際に発動します。電話通話とTicketトリガーの連携については、ライブ電話通話中の自動化アクションを参照してください。

Workflowsが期待通りに表示されない場合、セッションCookieが古いバージョンに紐づいている可能性があります。これを確認するには、シークレットモードやプライベートブラウジングでWorkflowsを開いてください。これによりキャッシュなしの最新バージョンが表示されます。問題が続く場合はブラウザのCookieをクリアし、ページを更新してください。また、Workflows内のフィルターや条件が誤動作することがあります。その場合は該当フィルターを再追加し、Workflowsを保存して再度ライブにしてください。

Workflowsは会話で開始されると、その時点でライブだったバージョンを使い続けます。Workflowsを再公開や更新しても、既に進行中の会話には影響しません。新しい会話は公開後の最新バージョンを使用します。

いいえ。Workflowsは特定の進行中の会話に対してリセットできません。会話は開始時のバージョンに紐づいたままです。すべての新しい会話に更新バージョンを適用したい場合は、変更を公開してください。新しい会話のみが反映されます。あるいはWorkflowsを複製して複製版をライブにする方法もあります。これにより新しいバージョン履歴を持つ新規Workflowsが作成され、新しい会話はそのバージョンで開始されます。

Workflowsの変更（条件追加、メッセージ更新、新ステップなど）は新しい会話にのみ適用されます。既に進行中の会話は開始時のバージョンを使い続けます。Workflowsを削除して再作成しても進行中の会話には影響しません。変更を確認するには、公開後に新しい会話を開始してください。

顧客が特定のボタンをクリックした後にWorkflowsが停止する場合、通常は「顧客の返信を収集」ステップが含まれているためです。このステップにより、顧客が入力を提供するまでWorkflowsは停止します。Workflowsを中断なく続行させるには、設定を見直し、必要に応じて「顧客の返信を収集」ステップを削除してください。

これは通常、複数のWorkflowsで割り当てアクションが同時にトリガーされるために起こります。優先度の高いWorkflowsが最終的な割り当てを決定し、他を上書きする可能性があります。問題解決のために以下を行ってください：

CSAT調査が意図せず複数回送信される一般的な問題は、チームメンバーが会話を繰り返し閉じる場合に発生します。これにより、同じやり取りに対して顧客が繰り返しCSAT調査を受けてしまい、顧客の不満を招くことがあります。CSAT調査を会話の閉鎖時に一度だけ送信するための手順は以下の通りです。

修正：CSAT調査を会話の閉鎖ごとに一度だけ送信する方法

チームメンバーが会話を閉じたときにCSAT調査が一度だけ送信されるようにするには、Workflowsの条件に特定のオーディエンスルールを追加する必要があります。以下のスクリーンショットは、Workflowsのオーディエンス設定で「Conversation rating requested is false」ルールが設定されている例です。

Workflowsの条件にオーディエンスルール「Conversation rating requested is false」を追加してください。

このルールにより、特定の会話に対して既にCSATリクエストが送信されていないことが保証されます。この重要な条件により、会話が複数回閉じられたり更新された場合でも、顧客に複数の調査リクエストが送信されるのを防ぎます。

Workflowsの競合を避けるには、Workflowsごとにユニークなオーディエンス設定を使用し、適切に優先順位をつけてください。論理接続子（「AND」対「OR」）を正確に設定し、非アクティブなトリガーや競合の定期監査などのベストプラクティスを採用してWorkflowsの信頼性を維持してください。Workflowsを区別するために明確な命名規則を使用し、新しい設定は様々な顧客シナリオでテストしてから展開してください。

Workflowsはチームメンバーが中断すると停止するよう設計されています。これはInboxからの変更でも再利用可能なWorkflowsに適用されます。会話イベントを確認して中断の原因となる更新がないか確認してください。

会話にマッチするWorkflowsがない場合、デフォルトの担当者に割り当てられます。デフォルト担当者を更新するか、Workflowsのオーディエンスルールを見直して適切にマッチングさせてください。

FinがSimple Deploy（Finの自動展開設定）で有効になっている場合、同じオーディエンスに対するカスタム割り当てWorkflowsより優先されます。これはFin for ServiceとFin for Ecommerceの両方に適用されます。Simple Deploy for Ecommerceがライブの場合、カスタムFin for Ecommerce Workflows、カスタムFin for Service Workflows、Fin for Service Simple Deployより優先されます。自動Workflowsは発動せず、WorkflowsトラブルシュートツールもこれらのWorkflowsを評価・表示しません。これにより、特定のinboxへの割り当てなどのカスタムWorkflowsステップが実行されません。FinとWorkflowsの自動化の競合を特定し解決するために以下の手順に従ってください。

Fin AI workflowが編集後にボットの返信をトリガーしなくなった場合、workflowのパスに「Let Fin answer」ステップが含まれているか確認してください。このステップを再追加してworkflowを公開すると機能が復元されます。

workflowがWhatsApp番号で分岐している場合、アクティブなWhatsApp Business numberが1つだけだと失敗することがあります。設定を簡素化してその単一番号を使用してください。番号が増えたら分岐ロジックを調整してください。

特定のメッセージが失敗する場合、Intercomではなくエンドユーザーに関連するMeta platform errorsが原因かもしれません。会話やMetaダッシュボードのメッセージエラー詳細を確認してください。

顧客がWhatsAppテンプレートに返信しない場合は、設定とメッセージの品質の両方を確認してください。

テンプレートの設定：

エラーログ：

プロフィールが会話より先に一致するとworkflowがトリガーされないことがあります。workflowの優先順位を正しくするために、必要に応じてWhatsAppメッセージを除外するようプロフィールを調整してください。

いいえ、workflowや再利用可能なworkflowからProcedureをトリガーすることはできません。ただし、Procedureの指示内でworkflowにハンドオフすることは可能です。

いいえ。Workflowsでは、Customer sends their first message、Ticket is created、New commentなどの事前定義されたトリガーから選択します。自動化が実行される条件を自然言語で記述するオプションはありません。

AI駆動のトリガーロジックが必要な場合、つまりFinが顧客の意図の説明に基づいて自動化を開始するタイミングを決定する場合は、代わりにFin Procedureを使用してください。ProcedureにはWhen to trigger設定内にBased on what the customer saysオプションがあり、FinがProcedureを実行する状況を記述できます。

first_nameとlast_nameフィールドはnameフィールドから自動生成され、別々には保存されません。そのため、workflowの分岐でフィルターや一致条件として使用できません。name属性を直接使ってフィルターしてください。個別にFirst NameやLast Nameでフィルターしたい場合は、カスタムデータ属性として作成し、統合を通じて値を渡してください。

Set changes liveボタンにFix issues in order to save.と表示され、ステップにエラーアイコンがない場合は、workflowのSchedulingセクションを確認してください。

元々将来の日付でライブに設定されていたworkflowは、ライブになった後もその予定日を保持します。その日付が過ぎると無効になり、更新するまで保存がブロックされます。過去の日付の停止日も同様です。

これをクリアして変更を保存するには：

1. workflowのSchedulingセクションを開きます。

2. Start sendingでImmediatelyを選択します。

3. Stop sendingで日付が過去の場合は、Neverを選択するか、将来の日付のCustom dateを選択します。

4. Set changes liveをクリックします。
​

workflowはライブのままで、編集内容は通常通り保存され、既存のオーディエンスとルールで実行され続けます。将来の停止日を選択した場合、その日付が過ぎるとworkflowは自動的に一時停止します。

Finish creating your workflow before setting it live と表示され、ステップにエラーアイコンがない場合は、workflowのSchedulingセクションを確認してください。

停止日が設定されたworkflowは、その日付が過ぎると自動的に一時停止します。期限切れの日付は設定されたままで、変更するまでworkflowの再ライブ化をブロックします。

再度ライブに設定するには：

1. workflowのSchedulingセクションを開きます。

2. Stop sendingでNeverを選択するか、将来の日付のCustom dateを選択します。

3. Set changes liveをクリックします。