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

workflowが会話で発動した時を以下から確認できます：

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

これは現在Workflowsではできませんが、機能リクエストとして提出することが可能です。

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

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

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

Intercomでoutbound bots（Workflows）にアクセスするには、以下の要件を満たしていることを確認してください：

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

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

workflowで「if」条件を作成し優先順位をつけるには、より多くの条件付きブランチを追加します。ブランチは上から下へ優先されます。

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

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

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

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

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

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

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

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

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

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

トリガーのオーディエンスで「Team assigned is [X]」を選択します。

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

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

可能な場合は、ライブ会話に予期せぬ影響を避けるため、まずステージング環境でテストしてください。

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

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

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

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

Workflows Preview機能で作成されたプレビュー会話はInboxに表示され、実際の会話として扱われます。つまり、プレビューユーザーの活動もworkflowのレポート指標に含まれます。送信数、エンゲージ数、完了数にはプレビューusersが実際の顧客と一緒に表示されます。

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

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

顧客が閉じたまたはsnoozedされた会話に返信すると、Intercomはworkflowの評価前に会話を再開（またはsnooze解除）します。顧客が任意のメッセージを送信workflowが条件を評価する時点では、会話はすでに開いているため、会話の状態 = Closedや会話の状態 = Snoozedの条件は一致しません。これにより、このworkflowで会話状態属性は条件として実質的に使えません。

同じ再開動作はsnoozed会話にも適用されます。顧客の返信によりworkflow評価前に自動的にsnooze解除されます。

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

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

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

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

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

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

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

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

いいえ。workflowステップで日付属性を設定することはできません。属性値を設定するworkflowアクション（例：会話データの設定）は日付属性タイプをサポートしていません。

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

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

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

電話から変換されたTicketsは元の会話の「Phone call」チャネルを保持します。これは、Teammate changes conversation stateのようなチャネル依存のworkflowトリガーが、チケットタイプではなく作成時のチャネルを評価するため、これらのTicketsでは発動しないことを意味します。

この制限はCSAT調査を含むすべての通話後の自動化に適用されます。CSAT調査を送信したり他の通話後自動化を実行するためにTeammate changes conversation stateトリガーに依存している場合、電話から始まったTicketsではこれらのworkflowはトリガーされません。

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

workflowが期待通りに表示されない場合、セッションCookieが古いバージョンにリンクされている可能性があります。これを確認するには、シークレットまたはプライベートブラウジングウィンドウでworkflowを開いてください。これによりキャッシュなしで最新バージョンが表示されます。問題が続く場合はブラウザのCookieをクリアし、ページを更新してください。さらに、workflow内のフィルターや条件が誤って登録されたり予期せぬ動作をすることがあります。この場合、影響を受けたフィルターを再追加し、workflowを保存して再度ライブに設定することで正常に機能します。

顧客が特定のボタンをクリックした後にworkflowが停止する場合、通常は「Collect customer reply」に設定されたステップが含まれているためです。このステップに従い顧客の入力があるまでworkflowは停止します。workflowを中断なく続行させるには、workflow設定を見直し、適切な場合は「Collect customer reply」ステップを削除してください。

これは通常、複数のworkflowsが同時に割り当てアクションをトリガーするために発生します。最も優先度の高いworkflowが最終的な割り当てを決定し、他を上書きする可能性があります。問題を解決するには：

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

修正：会話のクローズごとにCSATを一度だけ送信する方法

チームメイトが会話を閉じたときにCSAT調査を一度だけ送信するには、workflow条件に特定のオーディエンスルールを追加する必要があります：

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

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

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

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

会話に一致するworkflowがない場合、会話はデフォルトの担当者に割り当てられます。デフォルト担当者を更新するか、workflowのオーディエンスルールを見直して適切に一致するようにしてください。

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

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

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

テンプレート設定：

エラーログ：

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

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

first_nameとlast_nameフィールドはnameフィールドから自動生成され、別々には保存されません。そのため、workflow branchesでのフィルターやマッチングには使用できません。nameでフィルターする場合は、name属性を直接使用してください。個別にFirst NameやLast Nameでフィルターしたい場合は、Custom Data Attributesとして作成し、統合を通じて値を渡すことができます。