この記事を使ってWorkflowが期待通りに動作しない理由を診断します。主な原因は、Messengerと自動化設定、トリガーとオーディエンスの不一致、workflowの優先順位の競合、チームメンバーの操作とタイミング、チャネル設定、Fin AI Agentの競合、自動終了workflowの失敗です。
この記事はIntercomでWorkflowsを構築・管理するチームメンバー向けです。ここで説明する修正を適用するにはWorkflowsビルダーへのアクセスが必要です。
トラブルシューティングチェックリスト
始める前に、問題がよく発生する以下の重要なポイントを素早く確認してください。
基本設定：Messengerはアクティブで、Workflowsは正しいオーディエンスに対して有効になっていますか？
ルールとトリガー：オーディエンス、チャネル、トリガーの条件は意図した通りに設定されていますか？
Workflowの優先順位：期待しているものではなく、別のより一般的なworkflowが実行されていますか？
タイミングとチームメンバーの操作：チームメンバーの返信、スケジューリング、営業時間がworkflowの実行を妨げていませんか？
高度な条件：Ticketのステータスなど、特定のデータポイントは完全に一致していますか？
Workflowトラブルシューティングツール
Workflow Troubleshooting Toolを使って不一致の条件を特定します。ツールが不一致の条件を特定したら、該当するトリガールール、オーディエンス設定、またはworkflow内のデータ属性を期待される状態に更新し、同じ会話で再テストして問題が解決したか確認してください。
Workflowsの概要に移動します。
「Troubleshoot」をクリックし、会話のURLを貼り付けます。
結果を確認して、どの条件が一致し、どれが一致しなかったかを確認します。ツールはworkflowのトリガーを妨げているルールをハイライトします。
なぜMessengerがworkflowをトリガーしないのか？
workflow自体を確認する前に、Messengerと自動化設定が会話開始を許可するよう正しく設定されているか確認してください。
インバウンド会話設定
Control inbound conversation volumeはMessengerの設定で、誰が会話を開始できるかを制限できます。これにより顧客が会話を開始できなくなるため、「Customer opens a new conversation in the Messenger」「Customer sends their first message」「Customer sends any message」などの会話ベースのトリガーを持つWorkflowsはこれらの顧客に対して発火しません。
無効化されたMessenger
Show the Messenger LauncherはMessengerの設定で、顧客からMessengerを隠すことができます。Messengerが顧客から隠されている場合、「When a customer visits your site」「When a customer clicks on a website element」「When a customer opens the Messenger」などMessengerとのやり取りを含むWorkflowはこれらの顧客に対して発火しません。
自動化の基本
LeadsとUsers向けのSimple automations settingsでconversation ratingsをオンにしている場合、inactivity triggersの正常な動作を妨げることがあります。これにより他の顧客向けWorkflowsのトリガーが意図せず妨げられることがあります。
この問題を回避するには、以下の回避策を使用してください。
基本設定で会話評価を送信する代わりに、Workflowを作成してこれらの評価を送信するべきです。これにより今後の問題を防げます。
なぜ正しいトリガータイプが発火しないのか？
メールとアウトバウンドトリガーの不一致
「Customer sends their first message」や「Customer sends any message」などの特定のトリガータイプがどのworkflowを起動するかを決定します。例えば、「Customer sends their first message」は会話ごとに1回トリガーされ、「Customer sends any message」はその後の各メッセージでトリガーされます。この理解は予期しない重複なくworkflowを効果的に構築するために重要です。workflowでどのトリガーを選び、トリガー設定をどう構成するかが、誰がworkflowにマッチし、トリガーされるかを決定します。例えば、IntercomのAPIを使って作成されたチケットに対して「When a ticket is created」トリガーを使うと、顧客発信のメッセージが含まれず、workflowが発火しないことがあります。
メッセージ内容フィルター
workflowが特定のアクションで発火しない場合、ターゲット条件の不一致を確認してください。例えば、特定のメールでworkflowが発火しない場合、トリガー設定のメール条件が正しいか確認します。インバウンドメールのルーティングには「Customer Sends First Message」トリガーを使い、メール属性でフィルターすることを推奨します。アウトバウンドworkflowは「Customer visits a page」など特定のトリガー用で、通常会話開始とは連動しません。
workflowでメッセージ内容フィルターを使う場合、制限が厳しすぎないか確認してください。「Message content is」は完全一致が必要ですが、「Message content contains」は柔軟でトリガー成功率が上がります。
プロフィールタイプの不一致（Users、Leads、Visitors）
workflowトリガー設定時に、オーディエンス構成が意図に合っているか確認してください。workflowが「Users」のみを対象に設定されている場合、「Leads」発信の会話では発火しません。すべての対象者に対してworkflowを正しく起動させるには、オーディエンスルールを拡大して関連するすべてのグループを含めてください。
「Customer sends their first message」workflowを設定する際、初めて訪問したユーザーがMessengerを開いてworkflowをトリガーすると、その後はLeadと見なされますが、workflow内ではプロフィールのスナップショットを使うためVisitorとして評価されます。
WorkflowがLeadsとUsersのみを対象にしている場合、このVisitorには発火しません。すべてのプロフィールタイプを含めて、誰もがWorkflowにマッチするようにしてください。
さらに、顧客がメッセージを送信するメールアドレスがworkflowのターゲットオーディエンスとトリガー設定内で適切に定義されていることを確認してください。'Email to'や'Email recipient'などのフィルターを使って精度を高めます。転送メールを処理するworkflowは、転送先アドレスが正しく設定されており、自動転送が有効になっていることを常に確認してください。
例：
「When customer opens a new conversation in the Messenger」トリガーでworkflowを設定し、これらの会話すべてにタグを付けるステップを追加しました。
顧客がOutboundから送った投稿に返信しました。
この会話はタグ付けされません。なぜならMessengerで会話を開始しておらず（Outboundメッセージに返信したため）、タグ付けの対象外だからです。
すべての会話にタグを付けたい場合は、「When customer sends any message」トリガーを使うべきです。
正しい対象者（UsersとLeads）をターゲットにしていますか？
workflow（例えば営業時間外の応答）が「Users」を対象にしているのに会話が「Lead」とのものであれば、自動化は期待通りに動作しません。workflowのトリガー設定にUsersとLeadsの両方を含めるべきか常に確認してください。オーディエンスルールの誤設定は未処理のleadsやusersを生みます。
Audience targeting rulesはWorkflowの影響範囲に影響します。顧客が指定されたオーディエンス条件に合わない場合、Workflowは発火しません。workflowテスト時、"users only"設定のworkflowは、ユーザーが認識されない（訪問者やleadとして識別される）シークレットモードや特定ブラウザで失敗することがあります。包括的なテストには、workflowのオーディエンス設定を訪問者、leads、usersすべてを含むよう更新してください。例えば、Usersのみを対象にしたworkflowはLeadsでは発火しません。同様に、特定のタグや属性（例：to_drop_off_detected）が必要なworkflowは条件が満たされないと発火しません。
複数のworkflowがトリガーされるべきなのに、なぜ1つだけ実行されるのか？
顧客向けとバックグラウンドのWorkflows
IntercomのWorkflowsは顧客向けとバックグラウンドのworkflowに分類されます。顧客向けworkflowは自動メッセージ送信などの可視的なやり取りを含み、バックグラウンドworkflowは会話のタグ付けやスレッドのクローズなど顧客には見えない操作を行います。重要なのは、単一のトリガータイプに対しては1つの顧客向けworkflowのみが実行されますが、マッチするすべてのバックグラウンドworkflowは実行されることです。この区別により、異なるworkflowが競合せず共存できます。1つの会話で実行される顧客向けworkflowは1つだけです。同じトリガーに複数のworkflowがマッチする場合、Intercomはworkflow設定で最も優先度の高いworkflowを起動します。
会話中に実行できる顧客向けworkflowは1つだけです。顧客向けworkflowを中断し、別の顧客向けworkflowをトリガーできるチームメンバーの操作には以下があります：
開く
開いて再割り当て
コメント送信
スヌーズ
注意：顧客向けWorkflowsは、ステップを実行中だけでなく、顧客の返信を待っている間もスロットを保持します。つまり、最初のWorkflowsがアクティブな限り、たとえ新しいイベントが全く異なるトリガータイプを使っていても、後続のイベント（Ticket作成や新しい顧客メッセージなど）は新しい顧客向けWorkflowsを起動しません。例えば、Article Suggestion Workflowsが会話で入力待ちの場合、「When a ticket is created」Workflowsは最初のWorkflowsが中断または無効化されるまで発火しません。これを解決するには、ブロックしているWorkflowsを無効化または一時停止するか、チームメイトのアクション（開く、再割り当て、コメント、またはsnooze）で中断してください。
注意：バックグラウンドworkflowsはチームメイトのアクションに依存せず自動化を実行するよう設計されており、チームメイトが返信やsnoozeしても停止しません。
顧客向けWorkflowsが中断された後、別の顧客向けWorkflowsが自由に介入できます。
アウトバウンドメッセージへの返信は「customer sends their first message」に設定されたWorkflowsのみをトリガーし、「customer opens a new conversation」に設定されたものはトリガーしません。この区別により、異なる会話タイプに対してWorkflowsが正しく設定されていることを保証します。例えば、「First message」トリガーはアウトバウンドメールへの返信には発火しません。これらは既存の会話の継続とみなされるためです。
なぜ私のaudienceルールは正しい顧客にマッチしないのですか？
Audience targeting rulesはWorkflowに影響を与える対象を決定します。顧客が指定されたaudience基準に合致しない場合、Workflowは発火しません。
AND / ORルールは意図した通りに機能していますか？
Workflowsが複数の条件を"AND"で結合していて結果が不満足な場合、任意の条件を満たすことでWorkflowsをトリガーしたいなら"OR"ロジックに切り替えることを検討してください。すべての条件を満たす必要がある場合は、属性と値の設定が正しいことを確認してください。audience targetingで"OR"ルールを使う場合、1つの条件が真であればルールが適用されます。つまり、個々の条件のいずれかがマッチすれば、他の条件がマッチしなくてもWorkflowsはトリガーされます。
例：
次のロジックでCity属性に基づくaudienceルールを設定したとします：
"City is not Dublin" OR "City is not London"。
ユーザーがLondonにいる場合、ルールは次のように評価されます：
まず、City is not Dublinをチェック → ユーザーはLondonにいるため、この条件はtrueです。
"OR"ルールは1つの条件が真であればよいため、Workflowsは2つ目の条件をチェックしません（CityがLondonでないかどうか）。ルールはすでに満たされており、Workflowsは進行します。
つまり、DublinまたはLondonのユーザーは予期せずメッセージを受け取ったりWorkflowsをトリガーしたりする可能性があります。
ORルールはいずれかの条件が満たされるとトリガーされます。
否定的なORルールは、1つの条件が真になると他の条件が無視されるため、意図しないマッチを引き起こす可能性があります。
ANDルールを使用して、すべての条件が満たされた場合にのみWorkflowsをトリガーしてください。
分岐条件は特定のWorkflowsステップ内ではなくaudienceルールで設定してください。
これにより、最初から対象となる会話のみがWorkflowsを通過します。
したがって、DublinとLondonの両方のユーザーを除外したい場合は、"OR"ロジックから"AND"ロジックに切り替える必要があります：
"City is not Dublin" AND "City is not London"。
この設定では：
ユーザーはDublinにおらず、かつLondonにもいない場合にWorkflowsがトリガーされます。
どちらかの都市にいる場合、audienceルールはマッチせず、Workflowsはトリガーされません。
重要なポイント
IntercomのWorkflow audienceルールを設定する際：
ORルールはいずれかの条件が満たされるとトリガーされます。
否定的なORルールは、1つの条件が真になると他の条件が無視されるため、意図しないマッチを引き起こす可能性があります。
ANDルールを使用して、すべての条件が満たされた場合にのみWorkflowsをトリガーしてください。
個人データと会社データ
Workflowには個人データや会社データに基づく特定のトリガーがある場合があります。これらはIntercomで利用可能な標準またはカスタムデータ属性のいずれかです。トリガーの条件と基準を確認し、データが正しく入力され設定ルールに合致していることを確認してください。
例：
Workflowsで分岐を使う場合、次の条件をチェックすると：
"Company attribute is not"。
顧客は条件ルールに合致するために会社に紐づいている必要があります。会社がない場合、条件が真と判断せず、代わりに別のパスにフォールバックします。
会話がWorkflowsロジックでルーティングされる場合、特定の会社が設定されていなければ、システムはユーザーに最も最近更新された会社を使用します。否定的なORルールを使った分岐条件は順序に注意しないと予期せぬルーティングを引き起こす可能性があります。セッションで会社を指定し、分岐の順序を見直して正しいルーティングを確保してください。
"Last heard from"を使ったaudienceルールは、ちょうどメッセージを送った連絡先にマッチしません。
Workflowが"Last heard from is unknown"や"Last heard from is more than X days ago"のaudienceルールを使っている場合、メッセージを送った顧客に対してWorkflowsが発火しないことがあります。audienceサイズプレビューには表示されてもです。
これは予期された動作です。受信メッセージが届くと、IntercomはWorkflowsのaudienceマッチングが実行される前に連絡先の"Last heard from"タイムスタンプを更新します。マッチング評価時には連絡先は直前に連絡があった状態なので、両方の条件はfalseとなり、送信者に対してWorkflowsは発火しません。
注意：audienceサイズプレビュー（例：「980 people in your audience」）は現在の属性値を読み取り誤解を招くことがあります。ライブマッチングは受信メッセージ更新後の値を評価するため、プレビューに表示されていても実際に書き込むとマッチしないことがあります。これはMessenger、email、SMSなどすべての受信チャネルに当てはまります。
推奨される代替案：
連絡先履歴に関係なくすべての受信メッセージに対応するには：「Last heard from」ルールを完全に削除し、該当チャネルのLeadsとUsersをターゲットにしてください。
新規連絡先のみをターゲットにするには：「Signed up is unknown」を使います。この属性は受信メッセージでリセットされないため、競合状態がありません。
休眠連絡先を再活性化するには：「Last contacted is more than X days ago」を使います。「Last contacted」属性は最後に送信したアウトバウンドメッセージの日時を記録し、顧客が書き込んでも更新されないため、マッチング時に正確です。
タイミング、スケジューリング、またはチームメイトのアクションがWorkflowsをブロックしている可能性はありますか？
スケジューリングの使用で、Workflowがいつどのくらいの期間ライブになるかを制御できます。Workflowが発火しないのは、スケジュールの条件が満たされていない場合が多いです。外部要因により、すべてのルールが正しくてもWorkflowが実行されないことがあります。
チームメイトが先に返信やアクションを取りましたか？
チームメイトが会話を開く、再割り当て、コメントを送ると、アクティブな顧客向けWorkflowsを中断し終了させることがあります。同様に、Workflowsに時間遅延がある場合、遅延終了前にチームメイトが返信するとキャンセルされます。さらに、最後のメッセージがチームメイトではなくbotからの場合、応答なしトリガーのWorkflowsは起動しないことがあります。
カスタム日程スケジュール
Workflowにはカスタム日程スケジュールが設定されている場合があります。例えば、金曜の夜から土曜の朝までの間だけ発動するように設定されている場合です。この場合、これらの時間外にWorkflowをテストしても、どのtriggerが選択されていてもWorkflowは発動しません。例えば、Workflowが土曜日の00:00〜08:00 GMTに実行されるよう設定されている場合、同日の20:01 UTCに発生したイベントでは発動しません。
営業時間
Workflowが発動する時間帯としてOffice Hoursを設定している場合があります。営業時間内または営業時間外のいずれかです。Workflowsはチームごとに設定されたカスタム営業時間ではなく、デフォルトの営業時間のみを使用します。
Workflowのtrigger設定内でなく、conditional branchesとしてOffice HoursルールをWorkflow内に組み込むことを推奨します。
Trigger設定はお客様がMessengerとやり取りした時に評価されますが、branchesは会話中にリアルタイムで評価されるため、時間ベースの条件を扱うのにより適しています。
Workflowsは遡及的に適用されません
Workflowsは作成されてライブ設定された後に始まった会話にのみトリガーされます。Workflowが存在する前に始まった会話には、たとえすべてのtrigger条件を満たしていても適用されません。既存の会話を扱うには、手動で管理するか、既存の会話属性に作用するバックグラウンドWorkflowを使用してください。
チャネルの設定がWorkflowの発動を妨げている可能性はありますか？
WorkflowがEmail、SMS、またはソーシャルメディアなどの特定のチャネルに設定されている場合、そのチャネルが正しく接続されてアクティブであることを確認してください。チャネルが切断されているとWorkflowが発動しない原因となることがあります。さらに、Workflowのチャネル設定がユーザーのやり取り方法と一致していることを確認してください。例えば、Workflowが「email」のみでトリガーされるよう設定されていて、ユーザーがMessengerでやり取りした場合、Workflowは発動しません。Email Workflowの場合、設定でEmailチャネルが有効になっていることを確認してください。このチャネルがアクティブでないと、Emailの会話は該当するWorkflowをトリガーしません。例えば、Web、iOS、Androidチャネルを対象としたWorkflowはEmail会話では発動しません。
Emailを含むWorkflowsでは、trigger設定でEmailチャネルが正しく設定されアクティブであることを確認してください。また、Simple Deployが有効になっている場合はEmail Workflowsを上書きする可能性があるため確認してください。
注意：
「When customer sends their first message」Workflowを使用する場合、顧客向け要素が含まれていると、同じ顧客が開始した新しい会話の間に2分以上の間隔が必要です。間隔が2分未満の場合、Workflowは再度発動しません。
特にインバウンドのemail会話では、同じ送信者から数秒以内に複数のメールが届く場合、最初の1〜2通のメールのみが「Customer sends their first message」triggerにキャッチされます。その後の同時送信メールは「Customer sends any message」triggerにのみマッチします。会話が自動化なしで未割り当てで届く場合、このバースト動作が原因かもしれません。回避策として、影響を受けた会話内からCmd/Ctrl + K > Trigger reusable workflowで手動トリガーしてください。
同じWorkflowが複数回トリガーされるのをどう防げますか？
顧客メッセージに応答するWorkflowを設定する際、特にユーザーが追加の詳細を送信した場合に、同じWorkflowが会話内で複数回トリガーされるのを防ぎたいことがあります。
解決策：会話タグを使ってWorkflowのトリガーを制御する
Workflowが実行されたときに、会話に特定のタグ（例：「Pricing」）を追加します。
Workflowがトリガーされる前に、このタグがないことを確認するよう設定します。
この方法により、各Workflowは会話ごとに一度だけトリガーされ、重複した自動応答を防げます。
Workflowで参照されるタグは会話タグであることを確認してください。ユーザータグは会話レベルのフィルターやWorkflowでは使用できません。
このタグ付けシステムは、「Customer sends their first message」や「Customer sends any message」などの条件でトリガーされるWorkflowに特に有効です。フォローアップメッセージが自動化を再トリガーする可能性がある場合に役立ちます。さらに、タグは会話ごとに一度しか適用できません。既にタグが追加されている場合、Workflowは再適用しません。
なぜWorkflowが正しいページURLでトリガーされないのですか？
Workflowが正しいPage URLsやiOS・Androidデバイスの正しいアプリ内で発動するように正しく設定されていることを確認してください。これらの設定の誤りがWorkflowの発動を妨げることがあります。
URLターゲティングのベストプラクティス
Current page URLターゲティングは、「Where to send」セクションまたはTrigger rule設定内のメインのAudienceターゲティングセクションに追加できます。ただし、配置されるセクションによって機能が異なります。
Audience Targeting: ここでのURL設定は、最後に訪れたページに基づいてユーザーをターゲットにします。このデータは常に最新とは限らず、不正確なWorkflow発動につながることがあります。
Where to send: ユーザーが現在いる実際のページに基づく、より信頼性の高いターゲティングを提供します。通常、望ましい結果に一致します。
注意：「Where to send」セクションでURLターゲティングを使用すると、iOS・Androidのインバウンドボットが無効になります。モバイルアプリはURLを認識しないためです。URLターゲティングが重要な場合は、Web Messenger専用のボットとiOS・Android用のURLルールなしのボットを別々に作成してください。
シングルページアプリ（SPA）でのCurrent page URL
Workflow条件のCurrent page URL属性は、Messengerセッション開始時に追跡されたURLを反映しており、顧客の実際の現在のページではありません。シングルページアプリ（SPA）では、ページ全体のリロードなしにナビゲーションが行われるため、URLが古く見え、顧客が現在見ているページと一致しないことがあります。
注意：これはSPAのナビゲーション処理の既知の制限です。Messenger JSはフルページロード時にのみ再初期化されるため、動的なURL変更は自動的に追跡されません。
回避策：SPA内でルートが変わるたびに現在のURLをカスタムデータ属性としてプッシュするために、Intercom Messenger JS APIを使用してください。そのカスタムデータ属性をWorkflowのURL条件として使用し、Current page URLに依存しないようにできます。
APIで作成された会話のタイミング問題
'Current page URL'条件に依存するWorkflowsは、APIで作成された会話で失敗することがあります。URLが報告されるタイミングとAPI経由で会話が作成されるタイミングに差があるため、URL条件がタイムリーに一致しない可能性があります。APIで会話を作成しURLベースのトリガーに依存する場合は、慎重にテストするか、URLベースでない条件を使用してください。
Workflowブランチ内のURL条件
Workflowブランチ内のURL条件は会話作成時に評価されます。会話開始後に顧客が別のURLに移動しても、ブランチ条件は新しいURLを反映して更新されず、代わりにElseパスが実行されます。これを考慮して分岐ロジックを設計し、Messenger JS APIで更新されるデータ属性を使って動的URL追跡を検討してください。
なぜ「Current page URL」がFacebook/Instagram会話で機能しないのか
「Current page URL」フィルターはIntercom Messengerがインストールされているページにのみ適用されます。つまり、Facebookのような外部プラットフォーム発の会話のURLはキャプチャされません。これらのやり取りはあなたのウェブサイト外で行われるためです。
異なるチャネル（例：FacebookやInstagram）からの会話を正しくフィルターするには、「Page URL」フィルターを使用してください。このフィルターは参照元ページや外部ソースを追跡でき、会話が開始された場所に基づいて正しくセグメント化およびWorkflowトリガーが可能です。
記事ページでWorkflowがトリガーされない場合
記事URLをブロックしている可能性のあるオーディエンス除外ルールを確認してください。
他のWorkflowが私のWorkflowより優先されている可能性は？
会話が複数のアクティブなWorkflowのルールを満たす場合、Intercomは最も優先度の高いWorkflowのみを実行します。会話内で同時に実行できる顧客向けWorkflowは1つだけです。
他のWorkflowが先に実行されていますか？
Workflowは設定内の上から下へのリストで優先順位が決まります。一般的なWorkflowがリストの上位にあると、より特定のWorkflowが下位で実行されるのを妨げることがあります。重要なWorkflowが優先されるように優先順位を調整してください。
例：リストの上位にある一般的な「Welcome」Workflowは、顧客がVIPであっても下位の特別な「VIP Clients」Workflowを上書きします。
これを修正するには：
Fin AI Agentの設定がWorkflowを妨げている可能性は？
Fin AI Agentは時にWorkflowsと予期しない動作を引き起こすことがあります。Finに関連する一般的なWorkflow問題への対処方法は以下の通りです：
FinとWorkflowの優先順位付けとシンプルな展開
FinのSimple deploymentとworkflowsの両方が同じオーディエンスに対して有効になっている場合、Simple deploymentが優先され、Finのみが応答します。workflowsをトリガーさせるには、オーディエンスのターゲティングを調整して重複しないようにするか、Simple deploymentを無効にしてください。
Fin Workflowのクローズ時にCSATを有効化する方法
Customer Satisfaction Score (CSAT) WorkflowsはFinが会話をクローズした際に自動でトリガーされません。CSAT調査を送信するには、Workflow内の「Let Fin answer」ステップで設定してください。詳細な手順はFin CSAT documentationを参照してください。
同じ質問を繰り返し聞かれるusers
「Get context about issue upfront」に設定されたWorkflowsは、usersに同じ情報（例：名前、メール）を繰り返し尋ねることがあります。これを修正するには、Fin AI Agent > Simple Automation > Get context about issue upfrontの設定をusersとleads両方でオフにしてください。
FinのSimple deploymentによる干渉
FinのSimple deploymentが有効な場合、カスタムworkflowsを上書きし、訪問者が設定したIntercom workflowではなくFinの展開を見ることがあります。workflowsが期待通りにトリガーされない場合は、「Simple Deploy for Fin」を無効にしてworkflowsがusersに対してトリガーされるようにしてください。
Fin Workflowがメール処理に失敗する場合
メールベースのWorkflowsは、指定されたアドレスからIntercomへの正しい転送がされていないと失敗することがあります。メール転送設定を再確認してください。ここでのエラーはメール処理を妨げることが多いです。転送されたメールがworkflowのフィルター内で正しい受信者アドレスを含んでいるか確認し、自動転送が「ON」になっていること、指定された転送アドレスからのメールを完全に受け入れる設定になっていることを確認してください。メールがworkflowをトリガーしない場合は、workflowまたはオーディエンスターゲティングで正しいメールアドレスが設定されているか確認してください。サポートメールをworkflowのトリガー条件に追加すると問題解決に役立ちます。
メール転送とworkflowルール
メールが配信リスト経由で転送される場合、DMARC（Domain-based Message Authentication, Reporting and Conformance）準拠によりヘッダーが書き換えられ、domain条件が一致しないことがあります。
元の送信者情報を保持するには：
GoogleやMicrosoft 365のリダイレクトなどのサーバー側ルーティングでメールを転送し、Google Groupsのような配信リストは避けてください。
workflow評価における競合状態の防止
再割り当てが評価後に処理されると、workflowsが誤ってトリガーされることがあります。
このようなエラーを最小限にするには：
除外条件が最初に適用されるように条件の順序を見直す。
再割り当てシナリオでworkflowsを徹底的にテストする。
Finによる誤分類の回避
FinがIntercom workflow内の会話を誤分類する場合は、属性の説明を改善してマッチング精度を上げてください：
各属性に対して明確で文脈に沿った説明を書く。
顧客のフレーズに一般的に関連するdomain固有のキーワードを追加する。
サンプル会話で説明をテストする。
なぜ自動クローズworkflowが期待通りに動作しないのか？
自動クローズworkflowは、顧客の非アクティブ状態や事前定義されたworkflowアクションなどの特定のトリガーと条件に基づいて会話を自動的にクローズします。これによりinboxが整理され、会話の迅速な解決が保証されます。自動クローズworkflowがトリガーされない、早すぎるクローズ、予期せぬ中断がある場合はこのセクションを参照してください。
なぜ自動クローズworkflowがトリガーされなかったのか？
自動クローズworkflowがトリガーされない一般的な理由：
該当期間中の障害を確認してください。アクティブなインシデントがworkflowの実行を妨げている可能性があります。
トリガー条件が会話の状態に合っているか確認してください。例えば、オーディエンスが「Users」のみの場合、workflowは「Leads」にはトリガーされません。すべての関連プロファイルタイプを含むようにオーディエンスルールを拡張してください。
自動クローズworkflowが不適切に動作している場合、最も一般的な原因は：
Simple deploymentの競合：同じオーディエンスに対してFinのSimple deployment（一段階のFin設定で完全なworkflowロジックなし）が有効な場合、優先されて自動クローズworkflowのトリガーを妨げることがあります。これを解決するには、Simple deploymentを無効にするか、オーディエンスターゲティングを調整して重複しないようにしてください。
チームメイトの操作によるworkflow中断：会話の開封、再割り当て、コメントなどのチームメイトの操作は、アクティブな自動クローズworkflowを中断し、会話のクローズを妨げることがあります。非アクティブトリガーに依存するworkflowsは、チームメイトの操作で非アクティブタイマーがリセットされると失敗することもあります。
2分のクールダウン：顧客向けアクション（メッセージ送信など）を含むworkflowsは、同一顧客に対してトリガー間に2分のクールダウンがあります。これにより自動応答ループを防ぎますが、その間に会話が再開された場合、自動クローズが発動しないことがあります。安定した自動クローズのためには、顧客向けメッセージステップではなく、閉じるやタグ付けなどの非表示のバックグラウンドアクションのみを使った別のworkflowを作成してください。
なぜ自動クローズworkflowが予期せずトリガーされたのか？
自動クローズworkflowが不適切に動作している場合、最も一般的な原因は：
オーディエンスルールを見直してください。特にOR条件は1つの条件が満たされればよいため、顧客が意図せずworkflowにマッチすることがあります。
会話の状態変化を確認してください。例えば、ticketが「waiting_on_customer」にマークされている場合、トリガー条件を予期せず満たすことがあります。
なぜ会話が早すぎるか、または全くクローズされないのか？
workflow内の各Let Fin answerブロックには独自の自動クローズタイマーがあります。タイマーが短すぎると、顧客が応答する前に会話がクローズされることがあります。これを修正するには、Let Fin answerブロックをクリックし、自動クローズ設定を開いてタイマーの時間を延長してください。
workflowが動作しているのに会話が全くクローズされない場合は、以下を確認してください：
割り当てルールがworkflowクローズ後に会話を再開していないか確認してください。
Set expectation for human supportオプションを無効にした場合、Auto-close abandoned workflow conversationsのチェックボックスも無効になります。これは人へのエスカレーションが設定されている場合のみ利用可能です。エスカレーションなしで自動クローズを目指す場合はworkflowを調整してください。
自動クローズ設定はworkflowのトリガータイプに合わせて一貫性を持たせてください。例えば、非アクティブトリガーには同じブロックで非アクティブタイマーを設定する必要があります。
メールベースの自動クローズ
メールベースのworkflowsでは、転送メールに対応した自動クローズ設定が必要です。自動クローズアクションがworkflowのトリガー条件に合っているか、転送メールに正しい受信者アドレスが含まれているかを確認し、workflowが正しくマッチするようにしてください。
注意：複雑な分岐フローを使う再利用可能なworkflowでは、Closeアクションステップを追加することが最も確実なクローズ方法です。非アクティブタイマーだけに頼らないでください。
訪問者トリガーworkflowでデータコネクターが失敗する理由は？
データコネクターは識別されたコンタクトとアクティブな会話が必要です。ページ訪問でworkflowがトリガーされた直後にデータコネクターが実行されると、未識別の訪問者では失敗します。訪問者トリガーworkflowでデータコネクターを確実に使うには：
ページ訪問時にworkflowをトリガーする。
ボタン付きのメッセージを表示します。
ボタンがクリックされた後にデータコネクタを実行します。この時点で会話が存在し、連絡先を特定できます。
これらの領域を確認し、適切な設定を確認することで、Workflowが発火しない潜在的な原因を特定できるだけでなく、将来の操作のために正しく構成されていることを保証できます。👌
Workflowのデバッグにまだ助けが必要な場合は、Messengerを通じてサポートチームにお問い合わせください。
注意: iOSおよびAndroidのモバイルMessengerでは、Workflowステップで追加された埋め込み記事カードはユーザーに表示されません。モバイルユーザーがHelp Centerのコンテンツにアクセスできるようにするには、ハイパーリンク付きテキストを使用するか、記事に直接リンクするURLボタンを追加してください。