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をトリガーします。他のチャネルの会話には影響しません。

現時点では、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のレポート指標に含まれます。テスト後にレポート数値が予想外に高い場合は、プレビューユーザーの活動がカウントされているか確認してください。指標を正確に保つため、プレビューセッション後に送信・エンゲージ・完了数を見直すことを検討してください。

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

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

ライブになると、顧客が閉じた会話を再開するたびにIntercomが営業時間をチェックし、設定時間外であればメッセージを送信します。

顧客が閉じたまたはスヌーズされた会話に返信すると、Intercomはworkflow評価前にそれを再開（またはスヌーズ解除）します。Customer sends any messageworkflowが条件を評価する時点では会話は既に開いているため、Conversation status = ClosedやConversation status = Snoozedの条件は一致しません。これにより、このworkflowで会話状態属性は条件として実質的に使えません。

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

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つだけです。これを実現するには、「When customer sends their first message」の既存workflowを編集し、顧客の最初のメッセージを収集するステップを追加し、その後にフォローアップメッセージ「確認中です、しばらくお待ちください。」を送信するステップを追加してください。

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

いいえ。workflowステップでDate属性を設定することはできません。これは現在の製品の制限です。属性値を設定するworkflowアクション（例：Set conversation data）はDate属性タイプをサポートしていません。

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

workflowの「Conversation starter is 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では発動しません。

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

これを回避するには、代わりにチケットトリガーworkflowを使用してください（例：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自動メッセージworkflowでのみ利用可能です。

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

これらは通話ライフサイクルの異なるポイントで動作する2つの別々のトリガーです：

いいえ、テレマイトだけが通話中に切断した場合は発動しません。このトリガーは、顧客とすべての外部参加者が切断した通話の真の終了時に一度だけ発動します。テレマイトが切断しても顧客がまだ通話中の場合、通話は継続中でトリガーは動作しません。

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

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

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

状態の完全なリストと例のworkflowについては、Automate actions when a phone call endsを参照してください。

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

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

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

電話から作成されたticketでアクションを自動化するには、ticketトリガーworkflowを使用してください。例：A ticket is createdやTeammate changes the state of a ticket。これらはテレマイトが終了した通話を手動でticketに変換した時に発動します。電話通話とticketトリガーの連携についてはAutomate actions during live phone callsを参照してください。

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

workflowが会話で実行され始めると、トリガーされた時にライブだったバージョンを使い続けます。workflowの再公開や更新は進行中の会話には影響せず、開始時のバージョンに登録されたままです。公開後にトリガーされる新しい会話は最新バージョンを使用します。

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

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

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

これは通常、複数のworkflowが同時に割り当てアクションでトリガーされるために起こります。最も優先度の高い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のオーディエンスルールを見直して適切にマッチングされているか確認してください。

FinがSimple Deploy経由で有効になっている場合、カスタム割り当てWorkflowより優先されます。自動workflowは起動せず、workflowトラブルシューティングツールはこれらのworkflowを評価または表示しません。workflowを起動・評価可能にするには、FinセットアップでSimple Deployを無効にする必要があります。以下の手順に従い、FinとWorkflow自動化の競合を特定し解決してください。

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

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

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

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

テンプレート設定：

エラーログ：

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

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

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