【Salesforce】Web-to-ケースで意図した結果にならない時の管理者設定と利用条件の切り分け

SalesforceのWeb-to-ケース機能を使っていると、フォームから送信した内容が期待通りにケースとして作成されない、項目が正しくマッピングされない、もしくはまったくケースが生成されないという状況に遭遇することがあります。このような問題が起きたとき、原因が管理者側の設定ミスなのか、それとも送信元のWebフォームや利用者の環境に起因するのかを素早く切り分けることが重要です。本記事では、Web-to-ケースが想定と違う動作をした場合に、管理者設定と利用条件のどちらに問題があるのかを体系的に確認する方法を解説します。実際の社内トラブルシューティングに役立つ具体的な手順と判断基準をまとめました。

1. Web-to-ケースの仕組みと前提条件

Web-to-ケースは、外部のWebサイトや社内システムのフォームからSalesforceにケースを作成するための仕組みです。ユーザーがフォームを送信すると、指定されたエンドポイント(https://webto.salesforce.com/servlet/servlet.WebToCase?orgId=xxx)にHTTP POSTリクエストが送られ、Salesforceがそのデータを元にケースレコードを生成します。この機能を利用するには、管理者が事前に「設定」→「カスタマイズ」→「ケース」→「Web-to-ケース」からHTMLフォームを生成し、必要な項目を設定しておく必要があります。また、組織のセキュリティ設定によっては、送信元のIPアドレス制限やCSRF対策が影響する場合もあります。さらに、割り当てルールや自動応答ルールが有効になっていると、作成されたケースが自動的に特定のキューやユーザーに割り当てられるため、結果が意図と異なることがあります。これらの前提を理解したうえで、トラブルシューティングを進めてください。

2. 管理者設定の確認ポイント

最初に、Salesforceの管理画面で正しい設定が行われているかを確認します。以下の項目を順番にチェックしてください。

2.1 Web-to-ケースの有効化とHTMLソースの確認

「設定」→「ケース」→「Web-to-ケース」で、機能が有効になっているか確認します。無効の場合は有効に変更し、保存してください。また、生成したHTMLフォームのソースコードを開き、フォームのaction属性に正しいエンドポイントURLが設定されているか、hiddenフィールドのorgidが自組織のIDと一致しているかを確認します。よくある誤りとして、古い組織IDやデフォルトのURLがそのまま残っているケースがあります。

2.2 ケース項目のマッピングと必須項目の設定

Web-to-ケース設定画面では、フォームの項目とケースオブジェクトの項目を対応付けるマッピングが表示されます。送信したいデータが正しくマッピングされているか、また必須項目として設定した項目がフォームに含まれているか確認してください。もし必須項目がフォームに存在しない場合、その項目が空白でもケースは作成されますが、後続のプロセスでエラーになる可能性があります。注意点として、標準の「件名」「説明」などのほか、カスタム項目もマッピングできます。マッピングの欠落や誤りは、ケース作成後にデータが欠ける原因になります。

2.3 デフォルト値と事前入力項目

Web-to-ケースでは、フォームに表示されない項目にデフォルト値を設定できます。例えば「ケース原因」「ステータス」などを固定で指定したい場合に使用します。設定画面の「デフォルト値」セクションで、各項目に値が入っているか確認します。ただし、デフォルト値が設定されていると、フォームから送信された値があってもデフォルト値で上書きされるわけではありません(フォームに同名項目がない場合のみ適用)。想定と異なる値が入っている場合は、デフォルト値を変更するか、フォーム側で明示的に値を送信する必要があります。

2.4 割り当てルールと自動応答ルール

Web-to-ケースで作成されたケースには、組織で有効なケースの割り当てルールが適用されます。特定の条件に基づいてケースが自動的にキューやユーザーに割り当てられるため、意図しない担当者に割り当てられることがあります。同様に、自動応答ルールが有効だと、送信者に自動返信メールが送信されます。これらのルールが原因で、ケース作成後の動きが想定と異なる場合があります。管理者は設定を確認し、必要に応じてルールを一時的に無効にしてテストしてみてください。

3. 利用条件(送信元環境)の確認ポイント

管理者設定に問題がない場合、次にフォームを送信する側の環境や利用条件を確認します。以下の項目に沿ってチェックしてください。

3.1 フォーム送信の成功確認(HTTP応答)

Web-to-ケースは、正常に処理されるとHTTP 200、またはリダイレクト応答を返します。フォーム送信後にブラウザの開発者ツールでネットワークタブを確認し、エンドポイントへのPOSTリクエストのステータスコードを確認します。もし400番台や500番台のエラーが返っている場合は、フォームデータの形式や必須パラメーターの不足が疑われます。特に「400 Bad Request」の場合は、必須項目の欠落や不正な値が考えられます。また、送信後に表示されるページが「thankyou.html」などの成功ページに遷移しない場合、Salesforce側でエラーが発生している可能性があります。

3.2 ネットワーク制限とIP許可リスト

組織のセキュリティ設定で「信頼できるIP範囲」が指定されている場合、その範囲外からのWeb-to-ケース送信は拒否される可能性があります。また、ファイアウォールやプロキシによってアウトバウンド通信が制限されていると、フォームからのPOSTリクエストがSalesforceに到達しないことがあります。社内ネットワークから送信している場合は、ネットワーク管理者に問い合わせて、webto.salesforce.comへのHTTPS通信が許可されているか確認してください。外部のWebサイトにフォームを設置している場合も同様に、そのサーバーからのアクセスが許可される必要があります。

3.3 ブラウザの設定や拡張機能

まれに、ブラウザの広告ブロッカーやスクリプト制限機能がWeb-to-ケースの送信を妨げることがあります。特に、フォームがJavaScriptを使って送信処理を行っている場合は、拡張機能によって送信がブロックされる可能性があります。テスト時に別のブラウザやシークレットモードで試すと、原因の切り分けに役立ちます。また、フォームのエンコードタイプ(enctype)が「application/x-www-form-urlencoded」になっているか確認してください。ファイル添付がある場合は「multipart/form-data」が必要ですが、通常のテキスト項目のみの場合は前者で問題ありません。

4. 状況別の比較表:管理者設定 vs 利用条件

症状	管理者設定側の可能性	利用条件側の可能性
ケースが全く作成されない	Web-to-ケースが無効、組織ID誤り、エンドポイントURLが間違っている	ネットワーク遮断、IP許可リスト外、フォームのaction属性ミス、HTTPS通信エラー
ケースは作成されるが項目が空欄	マッピングが不足、デフォルト値が設定されていない、必須項目の設定漏れ	フォームのname属性がSalesforceの項目API名と一致していない、送信データのエンコード不正
ケースの割り当て先が想定と異なる	割り当てルールが想定外の条件で動作、キュー設定ミス	送信データに割り当てルールをトリガーする値が含まれている(例:特定の優先度)
ケース作成後、自動返信メールが届かない	自動応答ルールが無効、ルール条件不一致、メールテンプレート未設定	送信者メールアドレスがSalesforceの取引先責任者に紐付いていない、迷惑メール振り分け

5. よくある失敗パターンと判断基準

実際の現場でよく報告される問題パターンをいくつか紹介します。これらの事例を参考に、自身の状況と照らし合わせて原因を絞り込んでください。

5.1 フォーム送信後にエラーメッセージが表示される

例えば「There was an error processing your request.」と表示された場合、Salesforce側で内部エラーが発生している可能性が高いです。この場合、管理者にSalesforceのケース作成に関するエラーログを確認してもらう必要があります。また、開発者ツールでネットワーク応答の詳細を見ると、具体的なエラーコードが含まれていることがあります。

5.2 フォーム送信後に真っ白なページになる

成功ページにリダイレクトされず白紙になるケースは、サーバー側でエラーが発生したものの、エラーメッセージが表示されていない状態です。この時、HTTPステータスが200でもレスポンスボディが空の場合は、Salesforceが処理を完了したが何らかの理由で結果ページを返せなかった可能性があります。まずはフォームのaction URLを直接ブラウザで開き、HTTPS通信が確立できるか確認してみてください。

5.3 テスト環境では動くが本番環境では動かない

サンドボックスや開発組織でWeb-to-ケースが正常に動作するのに、本番組織で動作しない場合、組織の設定差分が原因です。例えば、本番組織ではIP制限が厳しい、割り当てルールが異なる、またはWeb-to-ケースの有効化が漏れていることが考えられます。本番組織の設定を再確認し、サンドボックスと比較してみてください。

6. 管理者に伝えるべき情報と連携手順

問題の切り分けができず、管理者に調査を依頼する場合、以下の情報を整理して伝えるとスムーズです。必要な情報を列挙します。

1. 問題の詳細:何が期待と異なるのか(ケース未作成、項目欠落、割り当て違いなど)。
2. 発生時刻と頻度:常に発生するのか、特定の時間帯や条件下でのみ発生するのか。
3. 送信元の環境:フォームが設置されているURL、使用ブラウザ、ネットワーク情報(IPアドレス、プロキシの有無)。
4. フォーム送信時のHTTPリクエスト詳細:開発者ツールからコピーしたリクエストヘッダーとボディ(ただし、orgidやパスワードなど機密情報はマスクしてください)。
5. Salesforce側の組織IDとWeb-to-ケース設定のスクリーンショット(不必要な情報は隠す)。

管理者はこれらの情報をもとに、Salesforceの設定や割り当てルール、セキュリティ設定を確認し、必要に応じてデバッグログを有効にしてテスト送信を再現します。また、Sandbox組織で同じフォームをテストすることで、本番環境との差分を特定できます。

7. よくある質問(FAQ)

Q1: Web-to-ケースでファイルを添付できますか?
標準のWeb-to-ケースではファイル添付はサポートされていません。添付が必要な場合は、別途ファイルアップロード機能を実装するか、メール-to-ケースを使用してください。

Q2: フォーム送信後、ケースが作成されるまでにタイムラグがありますか?
通常は即時作成されますが、大量のトラフィックがある場合や割り当てルールでの処理遅延が発生することがあります。数分以内に作成されなければ、何らかの問題が疑われます。

Q3: 特定のブラウザでのみ動作しないのはなぜですか?
ブラウザによってJavaScriptの挙動やセキュリティポリシーが異なるためです。特に古いInternet Explorerでは、フォーム送信時にCORSエラーが発生することがあります。可能であれば最新のChromeやFirefoxでテストしてください。

Q4: 送信者に確認メールを自動送信するにはどうすればいいですか?
Web-to-ケース設定とは別に、ケース作成をトリガーとする自動応答ルールを設定します。送信者のメールアドレスがSalesforce上の取引先責任者として認識されている必要があります。

まとめ

Web-to-ケースが想定と異なる場合、まずは管理者設定(機能の有効化、マッピング、デフォルト値、割り当てルール)を確認し、次に送信元の環境(ネットワーク通信、ブラウザ、フォームコード)をチェックしてください。問題の切り分けに迷ったときは、この記事で示した比較表と手順を参考に、一つずつ原因を潰していくことで解決につながります。なお、組織のセキュリティポリシーによっては、管理者以外が安易に設定を変更できない場合があるため、その際は適切な権限を持つ担当者に連絡を取りながら進めてください。最後に、トラブルシューティングの結果をドキュメント化しておくと、再発時の対応がスムーズになります。