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の任意の場所でAdd stepをクリックし、Tag conversationを選択してください。これは今後の会話にのみ適用され、遡及的には機能しません。

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

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

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

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

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内のクイックリプライボタンの表示はカスタマイズできません。

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

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

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

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

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

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

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

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

「会話開始者がOutbound message」のworkflowオーディエンスルールは、workspaceの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では発動しないことを意味します。トリガーは作成時のチャネルを評価し、チケットタイプではありません。

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

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

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

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

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

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

顧客満足度スコア（CSAT）調査が意図せず複数回送信される一般的な問題は、teammateが会話を繰り返し閉じる場合に発生します。これにより同じやり取りに対して繰り返しCSAT調査が送られ、顧客の不満を招く可能性があります。CSAT調査を一度だけ送信するための手順は以下の通りです。

修正：会話の終了ごとにCSATを一度だけ送信する方法

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

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

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

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

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

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

FinがSimple Deploy経由で有効になっている場合、カスタム割り当てWorkflowsより優先されます。これによりWorkflowsがスキップ、遅延、または上書きされることがあります。以下の手順に従い、Finとworkflow自動化の競合を特定し解決してください。

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

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

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

テンプレート設定：

エラーログ：

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

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

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