Zoho CRMの承認プロセスとは、条件に一致したレコードを承認者に回し、承認されるまで編集や削除を止めておく標準機能です。見積の値引きや受注の確定など、「上長が確かめてから次へ進める」業務でよく使います。
この承認プロセスが、条件どおりの状態にしたのに起動しない。設定を何度見直しても間違いが見つからない。当社が支援した中小の製造業（個別受注生産）で、まさにこの状態が起きました。原因は承認プロセスではなく、同じ見積モジュールに設定していたブループリントでした。
この記事では、そのときの調べ方と直し方を、再現しやすい手順にしてまとめます。ブループリントそのものの基本は「Zoho CRMのブループリント機能とは？使い方例をご紹介！」で解説しています。
起きたこと：条件に一致しているのに承認が起動しない
見積書には、次の2つの自動処理が設定されていました。
- ブループリント：「見積書作成中 → 見積提出済み → 受注処理前」と、見積のステージを決まった順に進める。途中で「失注処理」「見積辞退」も選べる
- 承認プロセス：見積書のステージが「受注処理前」になったら承認者に回す。承認後はステージを「受注」にし、関数で受注書を作る
ところが、ブループリントの「受注承認申請」でステージを「受注処理前」に進めても、承認待ちのロックも、承認・却下のリンクも出ません。受注書も作られません。お客様からは、以前は動いていたとのことでした。
承認プロセスの設定を確かめると、次のとおりで、設定の誤りはありませんでした。
- 実行タイミング：編集時
- 条件：見積書のステージが「受注処理前」
- 承認後の処理：ステージを「受注」に更新、最終承認後に受注書作成の関数を実行
なぜ承認プロセスが起動しないのか：ブループリントの途中にいるレコードは承認を通らない
Zohoの公式ヘルプ（ブループリントのトラブルシューティング）には、「ブループリントに入ったレコードは承認プロセスを通るか」という問いに対して、「通らない」と書かれています。あわせて、自動処理の実行順が示されています。
- 割り当てルール
- ワークフロールール
- 承認プロセス
- ブループリント
- ケースのエスカレーションルール
承認プロセスはブループリントより前に評価されます。ブループリントが動いているレコードを、後から承認プロセスが引き取る設計にはなっていません。
今回のブループリントでは、「受注処理前」がブループリントの最後の出口ではなく、途中の状態として残っていました。「失注処理」「見積辞退」の共通遷移（どの状態からでも選べる遷移）の対象に「受注処理前」が含まれていたため、そこへ進んだあともレコードはブループリントの管理下に置かれ続けます。その結果、承認の条件には一致しているのに、承認プロセスが起動しなかったのです。
「前は動いていた」理由
調べると、不具合が出る数日前に2つの作業をしていました。
- ステージの選択リストで、表示値と内部の値（実値）が食い違っていたものを、両方「受注処理前」にそろえた
- それに合わせて、見積のブループリントを編集し、再公開した
選択リストの整理で、承認プロセスの条件そのものは正しく一致するようになりました。一方で、ブループリントを公開し直したときに「受注処理前」が途中の状態として残り、承認へ渡す出口ではなくなっていました。直前の作業が引き金になった可能性が高い、というのが当社の判断です。
選択リストやブループリントを触ったあとに承認が止まった場合は、まずこの組み合わせを疑ってください。
ブループリントが原因かどうかはどう見分ける？：APIでレコードの状態を見る
画面だけでも見当はつきますが、レコードの状態はAPIで取ると確実です。Zoho CRMのレコード取得APIでは、fields に $approval_state を指定して承認の状態を取得できます。ブループリントの取得APIでは、そのレコードで今押せる遷移が返ります。
レコード取得の例です（{module} は見積モジュールのAPI名、{record_id} は対象レコードのID、ステージ項目のAPI名は環境に合わせて置き換えます）。
# レコードの状態を取得
curl "https://www.zohoapis.jp/crm/v8/{module}/{record_id}?fields=Quote_Stage,\$approval_state" \
-H "Authorization: Zoho-oauthtoken {access_token}"
# そのレコードで使えるブループリントの遷移を取得
curl "https://www.zohoapis.jp/crm/v8/{module}/{record_id}/actions/blueprint" \
-H "Authorization: Zoho-oauthtoken {access_token}"アクセストークンの用意は「Zoho APIをスクリプトから叩く最短ルート｜Self Client / Client Credentials設定」を参照してください。データセンターが日本以外の場合は、ドメインを読み替えます。
結果は、次の表のように読みます。表の値は、当社の案件でAPIから取得した値です（一般的な仕様として公式ドキュメントで確かめたものではありません）。項目名や返る値は、公式のAPIドキュメントでも確認してください。
| 見る値 | 承認が起動しているとき | 今回の不具合のとき |
|---|---|---|
| ステージ | 受注処理前 | 受注処理前 |
$approval_state |
approval_process_pending（承認待ち） |
approved（承認待ちではない） |
$approval の approve / reject |
true | false |
$process_flow |
false | true |
$editable |
false（承認待ちでロック） | true |
| ブループリントAPI | 遷移なし（HTTP 400） | 「失注処理」「見積辞退」が返る |
ポイントは $process_flow です。ステージが条件どおりでも、これが true でブループリントの遷移が返ってくるなら、レコードはまだブループリントの途中にいます。承認プロセスの設定を見直す前に、ここを確かめると遠回りしません。
承認プロセスとブループリントを両立させるには：直し方は2つ
どちらを選ぶかは、業務で何を残したいかで決まります。
案A：標準の承認プロセスを残す
承認の条件にしている状態を、ブループリントの出口（それ以上遷移しない状態）にします。当社では、こちらの案Aで修正しました（運用をどちらにするかの最終判断はお客様が行います）。
- ブループリントの編集画面を開き、承認の条件にしている状態（今回は「受注処理前」）を確認する
- その状態へ進む遷移（今回は「受注承認申請」）は残す
- 共通遷移（今回は「失注処理」「見積辞退」）の対象状態から、その状態を外す
- その状態に着いたあと、押せる遷移ボタンが1つも残らないことを確かめて公開する
- 新規または複製したレコードで、最初の状態から遷移させ直し、承認が起動するかを確かめる
- 承認後の処理（ステージ更新・関数の実行）まで、最後まで通して確かめる
この方法なら、承認履歴、承認待ちのロック、承認者の承認一覧画面といった標準機能をそのまま使えます。代わりに、承認待ちの間は「失注処理」などのブループリントの遷移が使えなくなります。
手順5で既存のレコードを使わないのは、修正前にすでに「受注処理前」へ着いていたレコードでは、承認が遡って起動するとは限らないためです。当社のケースでも、既存レコードはブループリントの管理から外れたものの、承認待ちにはなりませんでした。複製した見積で最初から通し直したところ、$approval_state が approval_process_pending になり、画面にも承認・却下のリンクが出ました。最終承認後には、受注書の作成関数も動きました。
案B：承認をブループリントの遷移として作り直す
標準の承認プロセスを使わず、ブループリントの中に「承認待ち」「受注」「見積却下」の状態と遷移を作ります。
- 承認申請の遷移の行き先を「承認待ち」に相当する状態にする
- 「承認」遷移の担当者を、承認者に限定する
- 「承認」遷移の遷移後処理（After Transition）で、受注書を作る関数を実行する
- 「却下」遷移で「見積却下」へ進める
- 必要に応じて、遷移時のコメント入力の必須化、チェックリスト、通知を設定する
この方法なら、承認待ちの間も「失注処理」「見積辞退」を残せます。ただし、標準の承認履歴や承認待ちのロックとは別物になります。承認者が複数いるときに「誰か1人でよいのか、全員が必要なのか」も、状態の設計で決めておく必要があります。
どちらを選ぶか
| 残したいもの | 選ぶ方法 |
|---|---|
| 標準の承認履歴・承認待ちのロック・承認一覧画面 | 案A |
| 承認待ちの間も、ブループリントの失注・辞退などの遷移 | 案B |
当社の調査メモでは、業務上「承認待ちでも失注・辞退を選びたい」なら案B、「標準の承認履歴とロックが必須」なら案Aを推奨としました。どちらも「承認とブループリントを同じ状態の上で同時に動かす」ことはできない、という前提に立っています。
再発させないためのチェックリスト
選択リスト・ブループリント・承認プロセスのどれかを変えたら、次を確かめます。
- 承認プロセスの条件に使っている項目と値は、選択リストの実値と一致しているか
- その値の状態は、ブループリントの途中の状態になっていないか（共通遷移の対象に含まれていないか）
- その状態に着いたレコードで、ブループリントの遷移ボタンが残っていないか
- 新規レコードで最初から遷移させ、
$approval_stateが承認待ちになるか - 承認後の処理（項目更新・関数）まで動くか
承認の起動を確かめる途中で、別のバリデーション（入力チェック）に止められることもあります。当社のケースでも、関連レコードの予定日が空で遷移が止まり、テスト用の複製レコードだけ値を補ってから再実行しました。承認の問題と入力チェックの問題を混ぜないよう、止まった理由は1つずつ記録しておくと、切り分けが楽になります。
承認ではなくワークフローの関数が「成功」と表示されるのに動かない場合は、「Zoho CRMのワークフローが「成功」なのに動かない｜関数の「入力値の関連付け」が空になる落とし穴」も確かめてください。ブループリントの代わりに、入力画面の流れだけを整えたい場合は「Zoho CRMのウィザード機能とは？使い方例をご紹介！」が参考になります。
まとめ
承認プロセスが動かないとき、設定画面の承認側だけを見直しても原因が見つからないことがあります。Zoho CRMでは、ブループリントの途中にいるレコードは承認を通りません。$process_flow とブループリントの遷移を見れば、どちらの問題かはすぐに分かります。
ブループリントと承認プロセスを同じモジュールで使うときは、「どの状態でブループリントが終わり、どこから承認が引き取るか」を設計の段階で決めておくことが、いちばんの予防になります。
承認フローやブループリントの設計・不具合のご相談は、Zoho CRMカスタマイズ・設定代行サービスから承っています。
よくある質問
承認プロセスの実行タイミングを「作成時」から「編集時」に変えれば動きますか？
レコードがブループリントの途中にある限り、実行タイミングを変えても承認は起動しません。実行タイミングの確認は必要ですが、条件に一致しているのに動かない場合は、先にレコードがブループリントの管理下にあるかを確かめてください。
ブループリントを直したら、すでに止まっているレコードも承認に回りますか？
当社が確認したケースでは、修正後に既存レコードはブループリントの管理から外れましたが、承認が遡って起動するとは限りませんでした。承認の動作確認は、新規または複製したレコードで、最初の状態から改めて遷移させて行います。
ブループリントの中で承認を回すことはできますか？
当社が確認した時点では、ブループリントの遷移から標準の承認プロセスを呼び出す設定は見当たりませんでした。代わりに、遷移の担当者を承認者に限定し、遷移後に関数を実行する形で、承認に相当する流れを作ります。この方法では、標準の承認履歴や承認待ちのロックは使えません。
Zoho CRMの承認プロセスが動かないとき、最初に何を確かめればよいですか？
承認の条件に使っている選択リストの値が実値と一致しているかと、そのレコードがブループリントの途中にいないかの2つです。ブループリントの途中にいるレコードは、承認の設定が正しくても承認を通りません。レコード詳細の上部に遷移ボタンが出ていれば、ブループリント側を先に見直します。
レコードがブループリントの管理下にあるかは画面で分かりますか？
レコード詳細の上部に、現在の状態と押せる遷移ボタンが表示されていれば管理下です。APIでは、レコードの $process_flow が true になり、ブループリントの取得APIで利用可能な遷移が返ります。
