Salesforceから移行する前の自動化の棚卸しとは、Salesforceで動いている選択リスト、Apexトリガー（レコードの変化で動くプログラム）、フロー、バッチ処理を一覧にし、それぞれをZoho CRMのどの仕組みで置き換えるか、あるいは置き換えずにやめるかを決める作業です。
移行前にどのデータ項目を確認すべきかは、SalesforceからZoho CRMへ移行する前に確認すべきデータ項目 で整理しました。この記事はその続きです。移行後の定着まで含めた全体の流れは、導入事例「SalesforceからZoho CRMの移行でコスト95%削減！」も参考になります。項目の対応が決まった後に残る「選択肢の値」と「自動で動いていた処理」を、非営利の会員制団体でSalesforceからZoho CRMへ移行したプロジェクトの記録をもとに紹介します。移行は進行中のため、成果ではなく、調べて分かったことと設計の考え方として書きます。
なぜ自動化の棚卸しが別に必要なのか
データ項目は、エクスポートしたCSVを見れば一覧になります。一方、自動化はCSVに出てきません。Salesforceの中で、レコードが作られたときに別のレコードを作ったり、夜間に将来の予定を作り足したりしている処理は、画面を使っている人が意識していないことも多いものです。
移行してから「前は自動で作られていたレコードができていない」と気づくと、その間のデータを手で直す必要が出ます。逆に、Zoho側に作った自動処理が移行データに反応して、余計なレコードを大量に作ることもあります。どちらも、移行の前に一覧を作っておけば防げます。
棚卸し1：選択リストは「項目があるか」「選択肢があるか」の2段で見る
選択リストとは、あらかじめ決めた選択肢から値を選ぶ項目です。Salesforceでは「選択リスト」「選択リスト（複数選択）」という型になります。
差分の取り方
当社では次の3つを突き合わせました。
- Salesforceの項目定義。オブジェクトごとに項目の一覧を書き出し、型が選択リストのものを抜き出します
- Salesforceの実データ。エクスポートしたレコードに、実際にどの値が入っているかを集計します
- Zoho CRMの項目一覧。項目一覧API（
settings/fields）で、モジュールごとの項目と選択肢を取得します
この3つを比べて、選択リストを次の4つの状態に分けます。
| 状態 | 意味 | 対応 |
|---|---|---|
| 未作成 | Zoho側に項目がない | 項目を作るか、不要なら作らないと決める |
| 選択肢なし | 項目はあるが選択肢が入っていない | 実データの値から選択肢を設定する |
| 設定済み | 項目も選択肢もある | 値の表記がSalesforceとそろっているか確かめる |
| 標準項目 | Zohoの標準項目に対応する | 標準の選択肢に寄せるか、選択肢を足す |
分かったこと
この団体では、Salesforce側の選択リストが複数のオブジェクトにまたがって多数あり、そのうち半数以上がZoho側に未作成でした。敬称、職種、言語のように、複数のオブジェクトに同じ名前で置かれている項目も多くありました。
選択肢の値は、項目定義だけでは足りません。実データを集計すると、項目はあるのに値が1件も入っていないものが見つかります。この場合は選択肢が分からないため、使うのか、どんな値を想定していたのかをお客様に確認しました。逆に、実データに入っている値から選択肢を組み立てると、使われていない古い選択肢を持ち込まずに済みます。
選択肢の設定は、スクリプトで差分のある項目だけを更新し、事前に「どの項目のどの選択肢が変わるか」を書き出して確認してから本番に反映しました。
棚卸し2：Salesforceのトリガー・フロー・バッチはZoho CRMの何に置き換えるか
次に、Salesforceで動いていた自動処理を一覧にし、Zoho CRMの仕組みに割り当てました。主なものは次のとおりです（処理名は一般的な言い方に置き換えています）。移行は進行中のため、置き換え先が決まったものと、まだ検討中のものを分けて書いています。
| Salesforce側の処理 | 何のための処理か | Zoho CRMでの置き換え先 | 状態 |
|---|---|---|---|
| Webフォームからのリードをキャンペーンに紐づけるApex | フォームの申込を施策ごとに数える | 作成時ワークフロー＋Deluge関数 | 確定 |
| 継続課金の作成時に会員情報を取引先（会員）へ反映するApexトリガー | 会員区分などを最新にする | いったん関数で作ったが廃止。フォーム連携の項目マッピングで直接渡す方式へ | 確定 |
| リードソースを別の項目へ写すフロー | 流入元を2つの項目で持つ | いったん関数で作ったが廃止。2つの項目を1つに統合 | 確定 |
| 将来の入金予定を作るバッチ（初回分） | 継続課金の予定を前もって並べる | 作成時ワークフロー＋Deluge関数で即時に作成 | 確定 |
| 同じバッチの延長分 | 予定が尽きる前に作り足す | 入金確定時のワークフロー → 日付ベースのワークフロー → 日次スケジュールと2回作り直した | 確定 |
| バッチが動かなかった分を見つける仕組み | 作り漏れを手で補う | 監視の関数を作ったが不要と判断して削除 | 確定 |
| 見込み客を変換するときの項目引き継ぎ | 流入元などを顧客側へ残す | Zohoの標準の変換マッピングで代わりにできないか検討中 | 検討中 |
| 入金確定時の通知メール（複数パターン） | お礼や担当部署への連絡 | 決済方法などの項目構造が決まってから設計 | 検討中 |
この表を作って分かったのは、1対1で移植するとかえって遠回りになるということです。
たとえば、会員情報を反映するトリガーとリードソースを写すフローは、最初はZohoでも同じ動きの関数を作りました。ところが、お客様と目的を確かめ直すと、前者はフォーム連携の側で値を渡せば足り、後者はそもそも項目を2つ持つ必要がありませんでした。結果として、この2つについては作った関数とワークフローを削除しています。
監視の仕組みも同じです。Salesforceでは予定の作成がバッチで後から動くため、動かなかった分を探す仕組みに意味がありました。Zohoではレコードの作成と同時に予定を作るため、探す対象がほとんど生まれません。元の処理が「非同期で動くから必要だった部分」は、置き換え先では要らなくなることがあります。
逆に、フォームのキャンペーン紐づけでは、移行のついでに独自の判定を足したところ、Salesforceの動きと結果が変わってしまいました。お客様と相談してSalesforceと同じ動きに戻しています。置き換えるときは、まず元と同じ結果になることを優先し、改善は移行の後に分けた方が安全です。
棚卸し3：仕様はコードより実データから読む
継続課金のレコードには、Salesforceで振られた「継続課金番号」がありました。当初はZohoで「既存の最大値に1を足す」採番を作りましたが、同時に複数のレコードが作られると番号が重なる問題が出ました。
そこでSalesforceからエクスポートした実データを調べると、継続課金番号は会員番号をそのまま写したものでした。会員（取引先）までたどれたレコードはすべて一致し、不一致はありませんでした。採番の処理をやめて番号を写すだけにしたことで、重複の問題も一緒に消えました。
Salesforceの設定画面やコードを読むより、実データを集計した方が早く確実に分かることがあります。移行前にエクスポートを手元に置き、「この値はどこから来ているのか」を数えて確かめるのは有効です。
Deluge関数では、次のように取引先（会員）の番号を読んで、継続課金のレコードを作るときにそのまま入れるだけです（項目名は一般的な名前に置き換えています）。
account = zoho.crm.getRecordById("Accounts", accountId);
recurring = Map();
recurring.put("Name", account.get("Account_Name") + " 継続課金");
recurring.put("Account", accountId);
// 採番せず、会員番号をそのまま写す
recurring.put("Recurring_No", account.get("Member_No"));
response = zoho.crm.createRecord("Recurring_Payments", recurring);
info response;移行データの投入でワークフローを動かさないには
自動化を置き換えた後は、その自動処理が移行データにどう反応するかを確かめます。今回の棚卸しで見つかった注意点は次の3つです。
作成時のワークフローは移行データにも反応する
継続課金のレコードが作られたときに将来の予定を作るワークフローは、手で作ったときにも動くよう、条件を付けずに設定していました。このままAPIやインポートで継続課金を移すと、移行したレコードすべてに対して予定がもう一度作られ、Salesforceから移した実際の予定と重なります。
APIで投入するときは、リクエストに trigger を空の配列で渡すと、ワークフローなどの自動処理を動かさずに作成できます（Zoho CRMのレコード作成APIの公式ドキュメントに記載があります）。
{
"data": [
{ "Name": "移行データ", "Recurring_No": "700001" }
],
"trigger": []
}この抑止を、移行手順書に明記しておくことが大切です。
過去の日付を基準にした処理は、移行データを拾わないことがある
日付を基準に動く自動処理は、基準日がすでに過ぎているレコードを拾わない場合があります。今回は延長分の作成を日次スケジュールに切り替えましたが、移行時点で予定がすでに尽きている継続課金は自動では拾われません。移行の手順の中で、一度だけの補充処理を別に流す必要があります。
自動採番の項目には既存の番号を入れられないことがある
Zoho側の会員番号は自動採番の項目でした。当社が確認した時点では、自動採番の項目にはインポートで既存の値を入れられませんでした。そのまま移すと番号が全件変わるため、旧番号を残すテキスト項目を別に用意するか、開始番号をどう設定するかを移行前に決める必要があります。前の節の「番号を写す」仕組みもこの決定に左右されます。
棚卸し4：レポートとメールの数も先に数える
自動化と並んで見落としやすいのが、レポートと自動送信メールです。この団体ではSalesforceのレポートが数十件ありました。全件を同じ形で作り直すのか、使われているものに絞るのかで、移行の範囲が大きく変わります。
絞り込むときの目安は、使用実績です。Salesforceのレポート一覧で最終実行日を見て、直近の数か月で開かれていないものは移行の範囲から外す候補にします。自動送信メールも、送信の条件（どの項目がどう変わったら送るか）と宛先を一覧にすると、項目の設計が決まるまで作れないものが見えてきます。最初に一覧を作り、どこまでを移行の範囲にするかをお客様と決めておくと、後から範囲が広がるのを防げます。
移行前の自動化棚卸しチェックリスト
- 選択リストを「未作成・選択肢なし・設定済み・標準項目」に分けたか
- 選択肢を、項目定義だけでなく実データの使用値からも拾ったか
- 値が1件も入っていない選択リストを、お客様に確認したか
- トリガー・フロー・バッチを一覧にし、それぞれの目的を書いたか
- 置き換え先（作成時ワークフロー、スケジュール、標準機能、廃止）を目的から決めたか
- 「非同期だから必要だった処理」を見分けたか
- 採番や転記のルールを、実データの集計で確かめたか
- 移行データの投入時に、作成時の自動処理を止める方法を手順書に書いたか
- 過去日付のデータと自動採番の項目の扱いを決めたか
- レポートと自動送信メールの数を数え、移行の範囲を決めたか
項目の対応表（マッピング）そのものの検証方法は「Zoho CRMへのデータ移行で漏れを防ぐ｜「要検討」項目を○×で潰し、マッピングを検証する方法」にまとめています。
Salesforceからの移行の全体像や進め方は、SalesforceからZoho CRMへの移行・乗り換え支援 でもご案内しています。ほかの企業の移行事例は、CRM移行事例の資料にまとめています。
よくある質問
Salesforceの選択リストはZoho CRMへ自動で移りますか？
Zoho CRMの移行機能でも項目を作れる場合はありますが、選択肢の値まで業務どおりにそろうとは限りません。当社では、Salesforceの項目定義とエクスポートした実データの使用値を突き合わせ、Zoho側の項目一覧APIの結果と比べて差分を出してから、選択肢を設定しました。
ApexトリガーやフローはZoho CRMで何に置き換えればよいですか？
レコードの作成時や更新時に動く処理は、ワークフロールールからDeluge関数を呼ぶ形が基本です。夜間バッチのように日付を基準に動く処理は、スケジュール処理で日次に回す方が確実な場合があります。項目の値を写すだけの処理は、Zohoの標準機能や連携側のマッピングで足りることもあります。
移行データを投入したときにワークフローが動いてしまうのを防ぐには？
APIでレコードを作成・更新するときに、リクエストの trigger を空の配列にすると、ワークフローなどの自動処理を動かさずに投入できます（当社が確認した時点の仕様です）。作成時に関連レコードを自動で作る処理がある場合は、二重作成を防ぐために必ず指定します。
Salesforceのレポートもすべて作り直す必要がありますか？
件数が多い場合は、全件を同じ形で作り直すかどうかを最初に決めるのがおすすめです。実際に使われているレポートを優先し、残りは移行後の利用状況を見て追加する方が、移行の範囲と期限を守りやすくなります。
