承認は「どの瞬間に」レコードになるのか
ServiceNowの承認は、画面に「承認待ち」が出てから追いかけようとすると混乱しやすいです。理由は単純で、承認は“概念”ではなくレコードとして生成されて初めてシステムが扱える対象になるからです。
結論から言うと、承認レコード（代表例：sysapproval_approver）は、次のどちらかの仕組みが「承認を作る」と決めた瞬間に作成されます。
- 承認エンジン（Approval Engine）が、そのテーブルの承認を管理しているとき
- ワークフロー／Workflow Studio（Flow Designerの承認アクション等）が、承認生成アクティビティを実行したとき
ポイントは、「対象レコード（例：ChangeやCatalog Request）が作られた瞬間に承認が必ず作られる」わけではないことです。承認は“生成処理が走ったタイミング”で作られる。ここを押さえると、調査が一気に楽になります。
まず押さえる用語：承認の“作成”と“状態更新”は別
- 作成：sysapproval_approver などのレコードがInsertされる
- 状態更新：承認者が承認・却下して state/approval が変わる（または自動で変わる）
「承認が作られない」のか、「作られているが通知やUIが出ない」のか、「作られて承認されたが親レコードに反映されない」のか。切り分けはここから始めるのが定石です。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
Approvalの主要テーブルと役割を地図でつかむ
承認を追うとき、テーブル名の印象が強くて迷子になりがちです。ここではCSA学習でも実務でも使えるように、“役割”で整理します。
承認の中心にいるのは sysapproval_approver
多くの場面で「承認待ち一覧」や「自分の承認」は、最終的に**sysapproval_approver（Approval）**レコードを見ています。つまり、承認が見える＝このテーブルにレコードがある、が基本線です。
ここで重要なのが、sysapproval_approverは「誰が承認するか」を表すテーブルだという点です。承認者がユーザーでもグループでも、最終的に“個人に割り当たる承認”として落ちてくる先がここ、という理解がいちばん実務的です（細かな実装差はありますが、追跡の起点としてはこれで十分戦えます）。
また、Flow Designerの承認（Ask for Approval）でも承認レコードが生成され、後続ステップでそのレコードにアクセスしたい、という相談が出るくらい、ここが中心です。
グループ承認が絡むと sysapproval_group が出てくる
「グループに承認依頼したい」ケースで登場するのが sysapproval_group です。イメージとしては「グループ承認の箱」。この箱の中身として、個々の承認者に紐づく sysapproval_approver が作られることがあります。Flow DesignerのAsk for Approvalでグループ承認を作る文脈でも、このテーブルが話題になります。
“親レコード”との紐づけが最重要
承認を調べるときは必ず「この承認は何の承認か」を確認します。そこがブレると、同名の承認・似た承認が大量に出てきて詰みます。
実務的な手順はこれです。
- 親レコード（例：CHG0001234）のsys_idを取る
- sysapproval_approverで、その親に紐づく承認を探す
- 見つかったら、そのレコードの生成元（どの仕組みが作ったか）を追う
以降のセクションで、「どの仕組みが作るのか」「いつ作るのか」を具体化します。
生成ルートは2系統：Approval EngineとWorkflow Studio
承認レコードの生成経路は、ざっくり2つに分けると理解が安定します。
Approval Engineが管理する承認
ServiceNowでは、タスク系テーブルごとに「承認エンジンを使うか」を設定できます。設定場所は System Properties > Approval Engines で、設定は glide.approval_engine.<table_name> というシステムプロパティとして保存されます。
ここで重要なのが、承認エンジンは“テーブル単位”で効かせる／止める、という設計になっている点です。つまり、
- そのテーブルの承認がApproval Engine管理なら、条件に応じて承認が生成される
- 逆に止めていれば、Approval Engineからは生成されない（別の仕組みが作る必要がある）
という見立てができます。
Workflow Studioや従来Workflowで生成する承認
もう一方が、ワークフロー側で承認を作るパターンです。ServiceNow公式ドキュメントでは、ワークフローを使って承認（ユーザー承認やグループ承認）を生成できること、そして承認プロセスを細かく調整できることが説明されています。
さらに重要なのが「競合」についての注意書きです。公式ドキュメントでは、ワークフローエンジンと承認エンジンの両方で同じテーブルの承認を管理すると競合が起きうるため、一般論として「ワークフローが承認を管理しているなら、そのテーブルの承認エンジンはオフがよい」とされています。
つまり「いつ作られる？」の答えはこうなる
- Approval Engineルート：エンジンが承認を生成する条件が満たされた時点で作られる
- Workflow/Studioルート：承認生成アクション（アクティビティ）が実行された時点で作られる
この理解があると、たとえば「レコードは作ったのに承認が出ない」時に、最初に見るべきものが決まります。
「このテーブル、承認エンジン有効？」「承認を作るフロー/ワークフローは本当に実行された？」です。
実務でハマる論点：競合・重複・追跡のコツ
ここからは、現場で“よくある詰まりポイント”を、仕組み理解とセットで整理します。暗記ではなく、考え方として持っておくと応用が利きます。
承認エンジンとワークフローの競合で起きること
公式が注意している通り、両方が同じテーブルの承認を触ると、現象が読みづらくなります。
よくある症状はこんな感じです。
- 承認が二重に作られる（似た承認が2つ並ぶ）
- 片方で承認しても、親レコードのapproval/stateが期待通りに変わらない
- 通知が多重送信される（承認レコード単位で通知が走るため）
原因は細部で色々ありますが、根っこは「承認を作る主体が複数いる」ことです。ここに気づけるだけで、調査の方向性がブレません。
ワークフローが作る承認には“参照情報”が入るが、使い方に注意
ワークフローが承認レコードを生成すると、承認レコード側に「どのワークフロー活動が作ったか」を示す参照が入る、という説明があります。ただし、そのフィールドをビジネスロジックに使うことは避けるよう注意されています。
つまり、「どの活動が作った承認か」は調査には役立つけれど、実装の前提に固定しない方が安全、ということです。CSA学習としても、ここは“なぜ注意されるのか”まで理解しておくと強いです（将来の変更に弱くなる、再利用性が落ちる、など）。
Ask for Approvalの次で「作られた承認」を触りたい問題
Flow DesignerのAsk for Approvalを使うと、承認が作られます。次のステップで「作られた承認レコードを取りたい」「個々のsysapproval_approverを更新したい」となるケースがあり、コミュニティでもその相談が出ています。
ここでの学びは、「承認は作られた瞬間からDB上に存在するので、レコードとして検索して触れる」ということ。逆に言うと、フローの中で“変数として持っているはず”と思い込むと迷います。
考え方はいつも同じで、親レコードとの紐づけ（何の承認か）をキーに辿ります。
トラブルシュートの最短ルート
承認が期待通りに動かないとき、私なら次の順で見ます。
- まずsysapproval_approverが作られているか（作られていなければ「生成」問題）
- 作られているなら、stateやapproverが正しいか（正しくなければ「生成ロジック」問題）
- 正しいなら、通知やUIが出る設定・権限・条件か（「表示」問題）
- 承認しても親が変わらないなら、親側の反映ロジックがどこか（「反映」問題）
- 競合しそうなら、そのテーブルの承認エンジン設定と、ワークフロー側の有効/無効を疑う
この順番は、承認に限らずServiceNow全般で効く“切り分けの型”です。
CSA学習のための理解の整理と学習手段の選び方
CSA学習で承認を扱うとき、細かいテーブル暗記よりも「説明できる状態」を目指す方が伸びます。おすすめの到達点はこれです。
説明できるようにしておきたいこと
- 承認レコードは「対象レコード作成」とは別で、「承認生成処理」が走った時に作られる
- 生成の主体は大きく2つ（Approval Engine / Workflow Studio）
- 同じテーブルで二重管理すると競合しうるので設計方針を決める
- 承認調査は、親レコード → sysapproval_approver の紐づけから辿る
これだけ押さえると、丸暗記なしでも選択肢問題やシナリオ問題で迷いにくくなります。
手を動かすなら、学習の順番はこうすると気持ちよく理解が進む
- まずは簡単なテーブル（例：自作テーブル）で、承認を作るフローを1本作る
- sysapproval_approverを実際に開いて、いつ増えるかを観察する
- Approval Engine設定を切り替えて、挙動の差を体感する（競合に注意）
本で読むだけだと「わかった気」になりやすい領域なので、1回でも“増える瞬間”を見ておくと記憶に残ります。
体系的に学ぶ教材の一例としてUdemyもアリ
承認は、Flow Designer／ワークフロー／権限／通知など周辺知識と結びつきやすい分、独学だと点で理解しがちです。もし「短期間で全体像をつかみたい」「手を動かす順番を案内してほしい」と感じたら、UdemyのServiceNow入門〜ワークフロー自動化の講座を“体系的に学べる教材の一例”として使うのも手です。
ブログ記事や公式ドキュメントで点を拾いながら、講座で線につなぐ、という組み合わせがやりやすいと思います。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まとめ
承認レコードが「いつ作られるか」を理解する近道は、承認を“画面の状態”ではなく“DBレコードの生成”として捉えることです。承認の中心は多くの場合sysapproval_approverで、ここにレコードがInsertされる瞬間が「承認が生まれた瞬間」になります。
そして、その生成ルートは大きく2つ。Approval Engineがテーブル単位で承認を管理して作るか、Workflow Studio／ワークフローが承認生成アクションを実行して作るかです。公式ドキュメントでも、同じテーブルで両者が同時に承認を管理すると競合が起き得るため、設計としてどちらを主にするかを決める重要性が示されています。
CSA学習では、テーブル名の暗記より「どう追跡するか」「なぜ競合するか」を説明できる状態を目標にすると、実務にもそのまま効きます。まずは親レコードからsysapproval_approverを辿って“増える瞬間”を観察し、必要なら講座などで全体像を線でつなげていく。この流れで、承認の理解はかなり安定してきます。
