flow-generation

Flow Designer フローの生成

概要

このスキルでは、自然言語の説明から ServiceNow Flow Designer フローを生成します。

• 適切なトリガー（レコードベース、スケジュールベース、アプリケーションベース）を使用したフローの作成
• 承認、通知、レコード操作、スクリプトステップなどのアクションの追加
• if／else 分岐や決定テーブルによる条件ロジックの構築
• 再利用可能な自動化コンポーネントとしてのサブフローの作成
• 並列／順次承認パターンによる承認フローの生成
• 動的コンテンツを使った通知フローの構築
• レコード変換や一括操作を行うデータ操作フローの作成

使用する場面： ビジネスプロセスの自動化、承認ワークフローの生成、通知ロジックの構築、または Flow Designer でのデータ操作パイプラインの作成を行う場合です。

前提条件

• ロール： flow_designer または admin
• プラグイン： com.glide.hub.flow_designer（Flow Designer）、com.glide.hub.action_type（Action Designer）
• アクセス権： sys_hub_flow、sys_hub_action_type_definition、sys_flow テーブル
• 知識： Flow Designer の概念（トリガー、アクション、フローロジック）の基本的な理解
• 関連スキル： Process Automation については genai/playbook-generation、インテグレーションについては genai/spoke-generation

手順

ステップ 1：自然言語の説明を分析する

ユーザーのリクエストを解析し、次の項目を特定します。

• トリガータイプ： フローを開始するもの（レコードの作成／更新、スケジュール、受信メール、REST）
• 対象テーブル： フローが操作するテーブル
• アクション： フローが実行する処理（レコードの作成、通知の送信、承認の要求）
• 条件： 分岐ロジックやフィルター
• 出力： 期待される結果または戻り値

ステップ 2：既存フローを照会してパターンを確認する

MCP アプローチ：

Use SN-Query-Table on sys_hub_flow:
  - query: active=true^trigger_type=RECORD_CREATED^table=incident
  - fields: sys_id,name,description,trigger_type,table,status
  - limit: 10

REST アプローチ：

GET /api/now/table/sys_hub_flow
  ?sysparm_query=active=true^trigger_type=RECORD_CREATED^table=incident
  &sysparm_fields=sys_id,name,description,trigger_type,table,status
  &sysparm_limit=10

ステップ 3：フローレコードを作成する

MCP アプローチ：

Use SN-Create-Record on sys_hub_flow:
  - name: "Auto-Assign Priority Incidents"
  - description: "Automatically assigns high-priority incidents to the on-call team"
  - trigger_type: "RECORD_CREATED"
  - table: "incident"
  - status: "draft"
  - run_as: "system"
  - scope: "global"

REST アプローチ：

POST /api/now/table/sys_hub_flow
Body: {
  "name": "Auto-Assign Priority Incidents",
  "description": "Automatically assigns high-priority incidents to the on-call team",
  "trigger_type": "RECORD_CREATED",
  "table": "incident",
  "status": "draft",
  "run_as": "system",
  "scope": "global"
}

ステップ 4：トリガーを設定する

主なトリガータイプとその設定：

トリガータイプ	値	設定フィールド
レコード作成	RECORD_CREATED	table, conditions
レコード更新	RECORD_UPDATED	table, conditions, fields_to_monitor
レコード削除	RECORD_DELETED	table, conditions
スケジュール	SCHEDULED	schedule, time_zone, repeat_interval
受信メール	INBOUND_EMAIL	target_table, conditions
REST API	REST	endpoint_path, http_method
サービスカタログ	SC_REQ_ITEM	catalog_item, conditions

MCP アプローチ：

Use SN-Create-Record on sys_hub_trigger_instance:
  - flow: "<flow_sys_id>"
  - trigger_type: "RECORD_UPDATED"
  - table: "incident"
  - condition: "priority=1^state!=6"
  - fields_to_monitor: "priority,assignment_group"

REST アプローチ：

POST /api/now/table/sys_hub_trigger_instance
Body: {
  "flow": "<flow_sys_id>",
  "trigger_type": "RECORD_UPDATED",
  "table": "incident",
  "condition": "priority=1^state!=6",
  "fields_to_monitor": "priority,assignment_group"
}

ステップ 5：フローアクションを追加する

一般的なアクションタイプと、それらが参照する sys_hub_action_type_definition：

アクション	タイプ定義	主な入力
レコードの作成	sn_fd.create_record	table, field_values
レコードの更新	sn_fd.update_record	record, field_values
レコードの削除	sn_fd.delete_record	record
レコードの検索	sn_fd.look_up_record	table, conditions
承認の要求	sn_fd.ask_for_approval	record, approvers, approval_type
メールの送信	sn_fd.send_email	to, subject, body
通知の送信	sn_fd.send_notification	notification, recipients
メッセージの記録	sn_fd.log	message, level
スクリプトの実行	sn_fd.run_script	script
条件の待機	sn_fd.wait_for_condition	table, condition, timeout

MCP アプローチ：

Use SN-Create-Record on sys_hub_action_instance:
  - flow: "<flow_sys_id>"
  - action_type: "<action_type_sys_id>"
  - order: 100
  - name: "Look Up Assignment Group"
  - inputs: {
      "table": "sys_user_group",
      "conditions": "name=Network Operations"
    }

ステップ 6：条件ロジックを追加する

フローロジックのステップを使って if／else 分岐を構築します。

MCP アプローチ：

Use SN-Create-Record on sys_hub_action_instance:
  - flow: "<flow_sys_id>"
  - action_type: "sn_fd.if"
  - order: 200
  - name: "Check Priority Level"
  - inputs: {
      "condition": "trigger.current.priority == 1"
    }

入れ子になった条件には、parent フィールドを使って子アクションを if／else ブロックにリンクします。

ステップ 7：承認フローを構築する

順次承認パターン：

Use SN-Create-Record on sys_hub_action_instance:
  - flow: "<flow_sys_id>"
  - action_type: "sn_fd.ask_for_approval"
  - order: 300
  - name: "Manager Approval"
  - inputs: {
      "record": "trigger.current",
      "approval_type": "approve_reject",
      "approvers": "trigger.current.opened_by.manager",
      "due_date_interval": "3 days"
    }

並列承認パターン： 並列ブロック内に複数の承認アクションを追加します。

Use SN-Create-Record on sys_hub_action_instance:
  - flow: "<flow_sys_id>"
  - action_type: "sn_fd.parallel"
  - order: 300
  - name: "Parallel Approvals"

次に、parent が並列ブロックを参照する子承認アクションを追加します。

ステップ 8：再利用可能なサブフローを作成する

MCP アプローチ：

Use SN-Create-Record on sys_hub_sub_flow:
  - name: "Send Escalation Notification"
  - description: "Reusable subflow for sending escalation notifications"
  - status: "draft"
  - inputs: "record,escalation_level,notify_group"
  - access: "public"

REST アプローチ：

POST /api/now/table/sys_hub_sub_flow
Body: {
  "name": "Send Escalation Notification",
  "description": "Reusable subflow for sending escalation notifications",
  "status": "draft",
  "access": "public"
}

ステップ 9：フローの入力と出力を定義する

MCP のアプローチ：

Use SN-Create-Record on sys_hub_flow_input:
  - flow: "<flow_sys_id>"
  - name: "assignment_group"
  - label: "Assignment Group"
  - type: "reference"
  - reference_table: "sys_user_group"
  - mandatory: true

Use SN-Create-Record on sys_hub_flow_output:
  - flow: "<flow_sys_id>"
  - name: "approval_status"
  - label: "Approval Status"
  - type: "string"

ステップ 10：フローを有効化してテストする

MCP のアプローチ：

Use SN-Update-Record on sys_hub_flow:
  - sys_id: "<flow_sys_id>"
  - status: "published"

フローが有効であることを確認します：

Use SN-Query-Table on sys_hub_flow:
  - query: sys_id=<flow_sys_id>
  - fields: sys_id,name,status,active

ツールの使用方法

ツール	目的	使用するタイミング
SN-Query-Table	既存のフローとアクションの種類を検索する	パターンの検出と検証
SN-Create-Record	フロー、トリガー、アクションを作成する	新しいフローコンポーネントの構築
SN-Update-Record	フロー設定を変更し、フローを有効化する	編集と公開
SN-Get-Table-Schema	フローテーブルのフィールドを確認する	利用可能な設定の把握

ベストプラクティス

1. フローは必ず最初にドラフト状態で作成します -- テストしていないフローを直接公開しないでください
2. フローやアクションには説明的な名前を付けます。ビジネス上の目的が伝わる名前にしてください
3. run_as は適切に設定します -- バックグラウンドの自動化には "system" を、ユーザーがトリガーするフローには "initiating_user" を使用します
4. エラー処理を追加します -- デバッグ用に try/catch ブロックとログアクションを含めてください
5. トリガー条件を制限します -- 範囲が広すぎるトリガーはパフォーマンスの問題を引き起こします
6. 複数のフローで繰り返し使用するロジックにはサブフローを使用します
7. 実行時の分析には sys_flow_context を使用してフローの実行を監視します
8. Wait for Condition アクションには適切なタイムアウトを設定し、無期限の停止を防ぎます
9. 本番テーブルに対して有効化する前に、アクセスが制限されたデータでテストします
10. 保守しやすくするため、description フィールドにフローの目的を記載します

トラブルシューティング

問題	原因	解決策
フローがトリガーされない	トリガー条件が厳しすぎるか、フローが無効になっている	sys_hub_flow.active とトリガー条件を確認します
権限エラーでアクションが失敗する	実行ユーザーにテーブルへのアクセス権がない	run_as を変更するか、フローユーザーにロールを付与します
フローが複数回実行される	トリガーに更新フィールドのフィルターがない	再トリガーを制限するために fields_to_monitor を追加します
サブフローが見つからない	サブフローがドラフト状態か、スコープが異なる	サブフローを公開し、アクセス設定を確認します
承認が保留中のままになる	該当する承認者がいない	承認者の参照先が有効なユーザーに解決されることを確認します
フローコンテキストにエラーが表示される	スクリプトアクションで実行時例外が発生している	詳細を確認するには sys_flow_context.error_message を調べます

例

例 1：インシデントの自動割り当てフロー

P1 インシデントをネットワーク運用チームに自動で割り当て、通知を送信するフローを生成します：

• トリガー：incident のレコード作成時。条件は priority=1
• アクション 1：sys_user_group で name=Network Operations のレコードを検索
• アクション 2：トリガーレコードの assignment_group に検索結果を設定してレコードを更新
• アクション 3：割り当て先グループのメンバーに通知を送信

例 2：変更リクエストの承認フロー

変更リクエスト用の多段階承認フローを生成します：

• トリガー：change_request のレコード更新時。条件は state=assess
• アクション 1：risk=high の場合、CAB 承認を要求（並列）
• アクション 2：risk=moderate の場合、マネージャーの承認を要求（順次）
• アクション 3：承認時に、状態を authorize に更新
• アクション 4：却下時に、却下メモを付けて状態を closed に更新

例 3：スケジュールされたデータクリーンアップフロー

古い解決済みインシデントをアーカイブする、スケジュールされたフローを生成します：

• トリガー：スケジュール実行、毎日 02:00 UTC
• アクション 1：incident で state=6^resolved_at<javascript:gs.daysAgo(90) のレコードを検索
• アクション 2：各レコードについて、u_incident_archive にアーカイブレコードを作成
• アクション 3：元のレコードを削除
• アクション 4：アーカイブした件数の概要をログに記録

関連スキル

• genai/playbook-generation - Process Automation Designer のプレイブック
• genai/spoke-generation - Integration Hub のスポーク作成
• catalog/approval-workflows - カタログ固有の承認設定
• itsm/incident-lifecycle - インシデントテーブルの構造とフィールド