目次
「前任者が作ったZoho CRMを、そのまま使い続けている」「設定画面にワークフローがたくさん並んでいるが、何が動いているのか誰も分からない」——こうした状態のCRMは、中小企業では珍しくありません。
普段の運用で困っていなければ、それでも回ります。問題が表に出るのは、データ移行やAPI連携でまとめて書き込むときです。眠っていたルールが一斉に目を覚まし、想定していないメール送信や項目の書き換えが起きる。さらにその書き換えが別のルールを起動し、連鎖していくことがあります。
この記事では、放置されたZoho CRMを棚卸ししたときに分かったことをもとに、ワークフローが連鎖発火する原因と、書き込む前に確認すべきポイントを整理します。
この記事の結論
- ワークフローのONは起動許可にすぎず、稼働の証明ではない
- 一括書き込みは休眠ルールを起こし、更新が連鎖発火を招く
- 書き込み前にAPI名基準でルールを洗い出し、確認は実行履歴で行う
Zoho CRMのワークフローが「ONなのに動いていない」とは
実案件（匿名）で、長く手入れされていなかったZoho CRMを棚卸ししました。設定画面では、多くのワークフローが有効（ON）になっていました。ところが実行履歴を確認すると、実際に動いていたのはごく一部だけでした。
では、残りのルールは壊れていたのか。そうではありません。設定は正しく、条件も成立し得る内容でした。ただ、条件に合うデータが来ていないため、起動する機会がなかったのです。
ここで押さえておきたいのは、ONという表示の意味です。
| 確認する場所 | 分かること | 分からないこと |
|---|---|---|
| 設定画面（ON/OFF） | 起動を許可しているか | 実際に動いたか |
| 実行履歴 | いつ・どのデータで動いたか | 将来どのデータで動くか |
ONは「条件に合えば動いてよい」という許可にすぎません。動いているかどうかは、実行履歴を見ないと分からないのです。そして「今は動いていない」ルールは、条件に合うデータさえ来れば、いつでも動き出します。
休眠ルールが突然発火する原因
普段の運用では、担当者が1件ずつ画面から入力します。入力のパターンは限られるため、多くのルールは条件に合わず眠ったままです。
ところが、データ移行やAPIでの一括書き込みでは事情が変わります。過去のデータや別システムのデータが、普段とは違う値の組み合わせでまとめて入ってきます。その中に休眠ルールの条件に合うデータが混ざっていれば、ルールは正しく、まとめて発火します。
さらに怖いのが連鎖です。ワークフローには、条件に合ったレコードの項目を更新する動作を持たせられます。その更新が、別のルールの条件を満たしてしまうことがあるのです。
1回の書き込みのつもりが、ルールからルールへと書き込みが広がっていく。どのルールが起点だったのかも、後から追いにくくなります。なお、どの書き込み経路でワークフローが起動するかはサービス側の仕様によります。仕様は変わるため、最新は必ず公式で確認してください。
切り分けを難しくした「表示名とAPI名の食い違い」
この案件では、もう1つ厄介な点がありました。項目の表示名とAPI名が食い違っていたことです。
画面に表示される名前と、システム内部で使われる名前が一致していないと、ワークフローの条件を読み違えます。「この項目なら関係ない」と思って見過ごしたルールが、実は今回書き込む項目を条件にしていた——ということが起こり得ます。
APIで書き込むときに指定するのはAPI名です。表示名だけを頼りに影響範囲を判断すると、確認したつもりで漏れが出るという構造になっています。
連鎖発火の対策：書き込む前の確認手順
ここまでを踏まえ、データ移行やAPI連携の前に行うべき確認は、次の順序で整理できます。
- 書き込む項目を決める：今回どのモジュールの、どの項目に、どんな値を入れるのかを先に確定させます。
- API名基準でルールを洗い出す：表示名ではなくAPI名で、その項目・値を条件にしているルールを探します。ONのルールはすべて、動き得る候補として扱います。
- 連鎖先をたどる：洗い出したルールが更新する項目を確認し、その項目を条件にする別のルールがないかを追います。
- 実行履歴で結果を確認する：少量のデータで試したあと、設定画面ではなく実行履歴で、どのルールが実際に動いたかを確かめます。
ポイントは、「今動いていないから安全」と判断しないことです。休眠ルールは壊れているのではなく、条件を待っているだけです。止めるべきルールが見つかれば、書き込みの前に一時的に無効化するか、条件を見直すかを判断します。
判断軸は2つだけ
細かい手順はいくつもありますが、持ち帰ってほしい判断軸は2つです。
- 書き込む前に、そのデータで起動し得るルールをAPI名基準で洗い出す
- 動作確認は、設定画面ではなく実行履歴で行う
1つ目は「起きる前」の確認、2つ目は「起きた後」の確認です。前者で影響範囲を絞り、後者で実際の挙動を確かめる。この2つをセットにすれば、放置されたCRMへの書き込みでも、想定外の連鎖を大きく減らせます。
よくある質問
Q. Zoho CRMでワークフローがONなら動いていると考えてよいですか？ いいえ。ONは起動を許可しているだけで、実際に動いたかどうかは分かりません。条件に合うデータが来ていなければ、ルールは眠ったままです。動作の有無は設定画面ではなく、実行履歴で確認してください。
Q. データ移行やAPIでの一括書き込みで、なぜワークフローが突然動くのですか？ 休眠していたルールの条件に合うデータが、一度にまとめて入るためです。普段は条件に合うデータが来ないだけで、ルール自体は壊れていません。さらに、ワークフローの項目更新が別のルールを起動し、書き込みが連鎖することもあります。
Q. Zoho CRMでワークフローの連鎖発火を防ぐには何を確認すればよいですか？ 書き込む前に、そのデータで起動し得るルールをAPI名基準で洗い出すことです。表示名だけで条件を読むと、対象項目を取り違えるおそれがあります。あわせて、動作確認は設定画面ではなく実行履歴で行うと、実際の挙動を把握できます。
まとめ
- ワークフローのONは起動の許可であり、実際に動いているかは実行履歴でしか分からない
- 動いていないルールの多くは壊れておらず、条件に合うデータを待って眠っているだけ
- データ移行やAPIの一括書き込みは休眠ルールを起こし、項目更新が別のルールへ連鎖することがある
- 表示名とAPI名の食い違いは見落としの原因になる。洗い出しはAPI名基準で、確認は実行履歴で行う
RENOYでは、放置されたCRMの棚卸しや、データ移行・API連携の前に「どのルールが動き得るか」を整理するところから、無料相談で承っています。「前任者の設定がそのままで、触るのが怖い」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。