Contents
前提条件と必要ロールの確認
ServiceNow Flow Designer を本番環境で利用するには、適切な権限が付与されたユーザーアカウントが必須です。ここでは、最低限必要となるロールと、その有無を確認・付与する手順をまとめます。権限不足はフローの作成やカスタムアクションの定義を阻害し、業務自動化全体に影響を及ぼすため、最初に必ずチェックしてください。
必要ロール
以下の2つのロールがあれば、Flow Designer のほとんどの操作が可能です。
| ロール | 主な権限 |
|---|---|
flow_admin |
フロー全体の作成・公開・バージョン管理 |
action_designer |
スクリプトベースのカスタムアクションの設計・保存 |
注意:ServiceNow のロール名は大文字小文字を区別しませんが、実際の定義はすべて小文字で格納されます。また、ロールは「アプリケーションスコープ」単位で管理されるため、対象フローが所属するスコープに対してロールが有効かどうかを必ず確認してください。
ロールの確認手順
- 画面右上のユーザーアイコン → 「プロフィール」 を選択し、表示されたダイアログで 「ロール」 タブを開く。
- 現在割り当てられているロール一覧が表示されるので、
flow_adminとaction_designerが含まれているか目視で確認する。 - いずれかが欠けている場合は、管理者権限を持つユーザーに 「ロール付与」 を依頼し、対象ロールを選択して保存してもらう。
詳細は ServiceNow 製品ドキュメントの [Roles and Scoping](2024 年 10 月版)をご参照ください。
URL: https://docs.servicenow.com/bundle/washingtondc-release-notes/page/product/role-management/concept/c_RoleManagement.html
Flow Designer の起動とメインパネル概要
本章では、実際に Flow Designer を開く手順と、画面構成の全体像を把握するためのポイントを解説します。UI が変わっても「左側ツリー・中央キャンバス・右側プロパティペイン」という三分割レイアウトは基本的に維持されているため、この構造を理解すれば新しいリリースでも迷うことはありません。
起動手順
- アプリケーションナビゲータ(左側メニュー)で「Flow Designer」と入力し、検索結果から対象アイテムをクリックする。
- 初回アクセス時に表示されるウェルカムパネルの 「開始」 ボタンを選択すると、フロー作成用のメイン画面がロードされる。
公式ガイドの最新手順は [Navigate to Flow Designer](2025 年 3 月更新)をご確認ください。
URL: https://docs.servicenow.com/bundle/paris-release-notes/page/product/flow-designer/concept/c_NavigateToFlowDesigner.html
メインパネル構成
| エリア | 役割・特徴 |
|---|---|
| 左側ツリー | フロー、サブフロー、標準アクション、カスタムアクションが階層的に表示され、ドラッグ&ドロップでキャンバスに配置できる。 |
| 中央キャンバス | ノード(トリガー・アクション・制御構造)を視覚的に組み立てる領域。自動接続線とズーム機能が備わっている。 |
| 右側プロパティペイン | 選択中のノードの詳細設定(入力変数、出力変数、条件式など)を編集でき、リアルタイムでバリデーションが走る。 |
このレイアウトは [Flow Designer UI Overview] にも図解付きで掲載されています。
URL: https://docs.servicenow.com/bundle/washingtondc-release-notes/page/product/flow-designer/reference/r_FlowDesignerUI.html
新規フロー作成ステップ
ここでは、実務で頻繁に利用される「申請・承認」シナリオを例に、フローの基本的な構築手順を段階的に紹介します。各ステップは UI 操作だけで完結できるため、開発経験が浅い担当者でもスムーズに進められます。
名前設定とトリガー選択
フロー名は業務目的が一目で分かるように命名し、トリガーは実行タイミングを正確に捉えるものを選びます。例として「HR_Leave_Request_Automation」という名前と、レコード作成時のトリガー設定手順を示します。
- フロー作成画面 の上部にある 「新規」 ボタンをクリックし、ポップアップでフロー名を入力する。
- トリガー選択 では「Record created」→対象テーブル
u_leave_request→ 条件state = Submittedを設定する。
トリガーの詳細は [Trigger Types] にまとめられています。
URL: https://docs.servicenow.com/bundle/washingtondc-release-notes/page/product/flow-designer/concept/c_TriggerTypes.html
標準アクションの追加方法
標準アクションは ServiceNow が提供する安全な API で、設定ミスが少なく迅速にロジックを組み込めます。以下では「Create Record」アクションを例に手順を解説します。
- 左側ツリーの 「Standard Actions」 セクションから
Create Recordを選択し、キャンバス上の適切な位置へドラッグする。 - 接続線で前後ノードと結び、右側プロパティペインで以下を設定する。
- テーブル:
u_leave_request - 必須フィールド:
requestor,requested_days(未入力の場合は赤字で警告表示)
標準アクションの一覧とパラメータ仕様は [Standard Action Reference] に掲載されています。
URL: https://docs.servicenow.com/bundle/paris-release-notes/page/product/flow-designer/reference/r_StandardActions.html
カスタムアクションのデザイン手順
action_designer ロールが付与されていれば、独自ロジックを JavaScript で実装したカスタムアクションを作成できます。以下は外部 REST API を呼び出す例です。
- アプリケーションナビゲータで 「Action Designer」 → 「New Action」 をクリックする。
- 名前・説明・対象スコープ(フローと同一スコープが推奨)を入力し、次へ進む。
- 入力変数 と 出力変数 をテーブル形式で定義する。(例:
request_id (String),approval_result (Boolean)) - スクリプトエディタに以下のようなコードを記述する。
javascript
var client = new sn_ws.RESTMessageV2('ExternalApproval', 'post');
client.setStringParameterNoEscape('request_id', inputs.request_id);
var response = client.execute();
outputs.approval_result = (response.getStatusCode() == 200);
- テスト実行 ボタンでサンプルデータを入力し、期待通りの出力が得られたことを確認したら「保存」→「公開」する。
- 作成済みカスタムアクションは左側ツリーの 「Custom Actions」 に表示され、標準アクションと同様にドラッグ&ドロップでフローへ組み込める。
カスタムアクション作成のベストプラクティスは [Create Custom Action] にまとめられています。
URL: https://docs.servicenow.com/bundle/washingtondc-release-notes/page/product/flow-designer/concept/c_CreateCustomAction.html
サブフロー活用と制御ロジック
サブフローは共通処理を一元化し、複数のメインフローから再利用できる重要な設計パターンです。また、If/Else や For Each といった制御構造を組み合わせることで、ほとんどの業務シナリオを表現できます。本章ではサブフローの作成手順と、条件分岐・ループ処理の設定ポイントを具体例付きで紹介します。
サブフローの作成と呼び出し方
共通ロジック(例:残業残高チェック)をサブフロー化すると、変更が発生した際に 1 カ所だけ修正すれば全体に反映されます。以下は Validate_Leave_Balance サブフローの作成手順です。
- 左側ツリーで 「Subflows」 → 「New Subflow」 を選択する。
- フローネームに
Validate_Leave_Balance、説明を入力し保存する。 - 入力変数として
employee_id (String)とrequested_days (Integer)、出力変数としてis_sufficient (Boolean)を定義する。 - 標準アクション(例:
Lookup Records)とカスタムロジックで残高計算を実装し、最終的にis_sufficientに結果を格納してサブフローを完了させる。
呼び出し方
メインフローのキャンバス上で 「Subflow」 ノードをドラッグし、作成した Validate_Leave_Balance を選択する。プロパティペインで入力変数にメインフローから取得したデータをマッピングし、出力は次の条件分岐ノードへ接続します。
サブフロー利用ガイドは [Subflow Best Practices] に詳述されています。
URL: https://docs.servicenow.com/bundle/washingtondc-release-notes/page/product/flow-designer/concept/c_Subflows.html
条件分岐・ループ処理の設定ポイント
制御構造は If/Else と For Each の 2 種類が中心です。以下に典型的な設定例と注意点を示します。
- 条件分岐(If/Else)
- 条件式は可能な限りシンプルに保ち、複雑なロジックはカスタムアクションへ委譲する。
-
例:
is_sufficient == true→ 「承認依頼」ノードへ、false→ 「不足通知」メール送信ノードへ分岐。 -
ループ処理(For Each)
- テーブルレコードの集合を対象にする場合は
Tableソースで取得し、各行に対して同一アクションを実行できる。 - 例:承認者リストテーブル
u_approver_listを走査し、各承認者へタスク作成(Create Record)を行う。
制御構造の詳細は [Control Flow Elements] にまとめられています。
URL: https://docs.servicenow.com/bundle/paris-release-notes/page/product/flow-designer/reference/r_ControlFlowElements.html
テスト・デバッグ、公開とベストプラクティス
フローを本番環境へリリースする前に必ずテストとデバッグを実施し、バージョン管理やアクセス制御で安全性を確保します。本章では、実務的なテスト手順から公開プロセス、さらに運用上のベストプラクティスまで網羅的に解説します。
テスト実行とステップ実行デバッグ
Flow Designer の 「Test」 機能はインタラクティブにフローを走らせながら変数の中身やエラーログを確認できるため、開発サイクルを大幅に短縮します。
- フロー編集画面右上の 「Test」 ボタンをクリック。
- テスト用入力データ(例:
employee_id = "E12345")を JSON 形式で入力し 「Start」 を押す。 - 実行中はノードがハイライト表示され、「Pause」 ボタンで任意のタイミングで停止できる。停止時にプロパティペインに現在の変数値が表示される。
- 下部の 「Debug Console」 に実行ログ・例外情報がリアルタイムで出力され、失敗したステップは赤字で示される。
デバッグ機能の詳細は [Testing and Debugging] を参照してください。
URL: https://docs.servicenow.com/bundle/washingtondc-release-notes/page/product/flow-designer/concept/c_TestingDebugging.html
フローの公開、バージョン管理、ロールベースアクセス制御
テストが完了したらフローを 「Publish」 状態に切り替え、バージョン番号を付与します。flow_admin ロールで行うバージョンロックにより、誤ってドラフト状態へ戻すことは防げます。
- フロー一覧から対象フローの 「…」 メニュー → 「Publish」 を選択。
- バージョン番号(例:
v3)を入力し 「Confirm」。公開後は自動的にロックされ、変更が必要な場合は新しいバージョンを作成する形になる。 - 各フローの 「Access Control」 タブで閲覧・実行可能なロールを指定できる。例えば
it_service_managerは実行権限のみ、hr_userは閲覧権限だけ、といった粒度の細かい設定が可能。
バージョン管理と RBAC のベストプラクティスは [Flow Publishing] にまとめられています。
URL: https://docs.servicenow.com/bundle/paris-release-notes/page/product/flow-designer/concept/c_FlowPublishing.html
実務例:申請&承認業務の自動化フロー
以下は「休暇申請」シナリオを実装したフローの構成例です。各ステップで使用するアクションやサブフロー、条件分岐が一目で把握できるように表形式で示します。
| ステップ | 使用要素 | 主な設定ポイント |
|---|---|---|
| 1️⃣ レコード作成トリガー | Record Created (u_leave_request) |
state = Submitted のみ対象 |
| 2️⃣ 残業残高チェック | Subflow Validate_Leave_Balance |
入力: employee_id, requested_days |
| 3️⃣ 条件分岐 | If/Else (is_sufficient) |
true → 次へ、false → 「不足通知」メール送信 |
| 4️⃣ 承認依頼作成 | Create Record (u_approval_task) |
承認者リストを For Each で走査 |
| 5️⃣ 承認結果待ち | Wait for Condition (approval_status == "approved") |
タイムアウトは 48 時間に設定 |
| 6️⃣ 完了処理 | Update Record (u_leave_request) |
state = Approved に更新 |
| 7️⃣ 通知メール送信 | Send Email | 承認者と申請者双方へ通知 |
この構成は ServiceNow Community の実装例(2024 年 11 月)でも紹介されています。
設計上の注意点と最適化ポイント
- スコープ設計:フローは業務アプリケーションの同一スコープで作成し、他システムへの影響を最小限に抑える。
- パフォーマンス最適化:大量レコード処理は
For Eachの代わりにバルク API(例:Bulk Insert)を利用し、API 呼び出し回数と実行時間を削減する。 - エラーハンドリング:全アクションに対して 「Error Handling」 ノードを配置し、失敗時は自動で管理者へアラート(
Send Email)を送信する。 - ドキュメンテーション:フローの 「Description」 フィールドに目的・前提条件・バージョン履歴を記載し、チーム内で共有できるようにしておく。
- ロールベースアクセス:公開時に 「Access Control」 で実行権限だけを必要とするユーザーに限定し、閲覧のみが許可されたロールには編集権限を付与しない。
上記ベストプラクティスは [Flow Designer Best Practices] に詳細が掲載されています。
URL: https://docs.servicenow.com/bundle/washingtondc-release-notes/page/product/flow-designer/concept/c_BestPractices.html
参考リンク(2026‑07‑05 更新)
以上が、ServiceNow Flow Designer を実務で安全かつ効果的に利用するための包括的な手順と留意点です。この記事を参考に、まずはテスト環境で簡単なフローを作成し、段階的に本番導入へ進めてください。