受信メールでチケットが立つ仕組み（Inbound Email Action）

ServiceNow で「サポート宛にメールを送るとインシデントが起票される」「通知メールに返信すると、そのチケットが更新される」といった挙動があります。これは Inbound Email Action（受信メールアクション） という仕組みで動いています。送信側の Notification（sysevent_email_action）が外へメールを出す役だとすると、Inbound Email Action は受信側の対です。届いたメールを読んでレコードを作る/更新します。

この記事では、受信メール処理をプロセス論ではなく、実際のテーブル sysevent_in_email_action（Inbound Email Actions） を起点に追います。受信メールがどの種別（New / Reply / Forward）に判定され、どの対象テーブル（Target table）に対して、どの条件・スクリプトで動くのか。PDI（Personal Developer Instance）の OOTB を実機で開いて、フィールドと件数で確認します。

この記事は、ServiceNow の Incident は触ったことがあるが、受信メールがどのテーブルを通ってレコードになるのかをこれから理解したい人を想定しています。管理者・開発者が「メールしたのに起票されない」「返信したのに別の新規が立った」を切り分けるときに見るべき、テーブルと項目をまとめます。

この記事で分かること

• 受信メールがレコードになるまでの流れ（受信→email.read 発火→種別判定→受信アクション実行）

• 受信アクション sysevent_in_email_action が「いつ・どこに・何を」をどの項目で持つか

• 受信種別 Type の 3 値（New / Reply / Forward） が何で決まり、それぞれ既定でどう動くか

• 対象テーブル（Target table）と Action type（Record Action / Reply Email）の意味

• OOTB に最初から入っている受信アクションの件数と分布（incident が最多）

• 送信側 Notification との対の関係（watermark で返信を既存レコードに紐づける）

Inbound Email Action（受信メールアクション）とは

Inbound Email Action は、受信したメールを読んで対象テーブルにレコードを作る/更新するルールです。届いたメールの種別（新規か返信か転送か）と条件を見て、合致すれば script を実行してレコードを操作します。設定は sysevent_in_email_action テーブルに保存され、画面ラベルは Inbound Email Actions です。

送信側 Notification と同じ Rule ファミリー

受信アクションは、Business Rule（ビジネスルール）に似た「条件＋スクリプト」のルールです。今回確認した PDI（Zurich / OOTB）では super_class が sysrule（Rule）でした。送信側の Notification（sysevent_email_action）と同じ Rule（メタデータ）系として管理されていました。送信と受信のメール処理は、どちらも同じ Rule ファミリーの上に乗っています。

公式の概要は Inbound email actions で説明されています。受信メールに対し、条件とスクリプトでレコードを作成/更新するルールであることが述べられています。

受信メールがレコードになるまで

まず全体像です。今回確認した PDI（Zurich / OOTB）では、受信メールは次の流れでレコードになる構成でした。

• ① 受信 … メールがインスタンスのメールアドレスに届き、メールレコード sys_email（type=received）として取り込まれます。

• ② 発火 … メールが読まれると email.read イベントが発火します（今回の OOTB の受信アクションは 14 件すべてこのイベントを待ち受けていました）。

• ③ 種別判定 … その受信メールが New / Reply / Forward のどれかが判定されます。

• ④ 受信アクション実行 … 種別が一致する受信アクションが Execution Order（order）順に評価され、条件に合えば script でレコードを作成/更新します。

「受信メール（sys_email）」と「受信アクション（sysevent_in_email_action）」は別物です。sys_email は届いた 1 通の実体です。sysevent_in_email_action は「この種別のメールが来たらこう処理する」というルール、と捉えると切り分けやすくなります。

なお、今回の PDI（OOTB）には実際に受信したメール（sys_email の type=received）は 0 件でした。受信を実際に流すフローの挙動は実機で再現していないため、本記事は「受信アクションの定義テーブル」の構造確認にとどめます（受信の実フローは検証範囲外）。

受信種別 Type（New / Reply / Forward）の分かれ方

「メールしたのに思った通りに動かない」とき、まず見るのは Type（受信種別）です。受信アクションは Type ごとに分かれていて、届いたメールの種別と一致する Type のアクションだけが動きます。今回の PDI では Type は 3 種類でした。

Type ごとの既定の動き

• Reply（返信） … 件名や本文に watermark（ServiceNow が通知メールに自動で埋め込む識別文字列）や既存レコード番号があり、既存レコードに紐づくメールです。既定では既存レコードを更新します。

• Forward（転送） … 件名に FW: などの転送プレフィックスがあり転送と判定された受信メール。既定では新規レコードを作成します。

• New（新規） … 上記いずれにも当たらない受信メール。既定では新しいレコード（OOTB では incident）を作成します。

この watermark で「返信を既存チケットに紐づける」仕組みが受信処理を成り立たせています。公式は Watermarks on notification emails で、通知メールに埋め込んだ識別文字列で返信メールを元レコードに対応づける、と説明しています。種別判定の細かな条件は Inbound email action processing が受信メールの処理の流れを述べています。判定アルゴリズムの内部実装はサーバ側の処理で実機の REST からは取得できないため、本記事では検証範囲外とします。

受信アクションの一覧は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sysevent_in_email_action_list.do?sysparm_query=ORDERBYtype

受信アクションの構成要素（いつ・どこに・誰の・判定・何を）

受信アクションは「いつ（Type/順番）・どこに（対象テーブル/Action）・誰のメールか・送るか判定・何をするか」の 5 つの軸で読むと迷いません。固有フィールドは今回の PDI で 15 ありましたが、フォームのどの項目もこの 5 軸のどれかに収まります。

• いつ … type（Type＝New/Reply/Forward）と order（画面ラベル Execution Order）。同じ種別内では order が小さいものから評価されます。

• どこに … table（Target table＝作成/更新する対象テーブル）と action（Action type）。

• 誰のメールか … from（この送信者からのメールだけ動かす）と required_roles（送信者が持つべきロール）。

• 判定 … filter_condition（Conditions・条件ビルダ）と condition_script（スクリプト条件）。

• 何をするか … script（レコードを作成/更新する処理本体）と template（Field actions・フィールド設定）。

Action type（Record Action ／ Reply Email）の使い分け

Action type（action）は今回の PDI では 2 値でした。Record Action（スクリプトでレコードを操作）と Reply Email（送信者に返信メールを送る）の2つです。OOTB の 14 件はほぼ Record Action（13 件）で、レコード操作が中心の構成でした。

実機のフォームを見ると、これらの軸が画面上でそのまま並んでいるのが分かります。次は OOTB の「Create Incident」（Type=New・Target table=Incident）のフォームです。

公式の作成手順は Create an inbound email action で、Type・Target table・When to run（条件）・Actions（script）という同じ並びで項目が説明されています。

OOTB に入っている受信アクションと対象テーブル

参考として、OOTB に最初から入っている受信アクションの件数と分布を載せます。今回確認した PDI（Zurich / OOTB・active中心・2026-06-20確認）の値です。

OOTB の時点で 14 件（うち active 13 件）の受信アクションが登録済みで、自分で作らなくても「メールでインシデント起票」「返信でチケット更新」がひと通り動く構成でした。分布には次の傾向がありました。

• Type は Reply が最多（10 件）。受信処理は「新規作成」より「既存レコードの更新」が中心です。New は 3 件、Forward は 1 件でした。

• 対象テーブル（Target table）は incident が最多（5 件）。incident に対して Create（New）/ Create Forwarded（Forward）/ Update 系（Reply）が揃っていました。他には problem / change_request / change_task があります。sysapproval_approver / sc_req_item / live_message もあります。それぞれ 1 件ずつ分かれていました（具体名は下の一覧を参照）。

• 承認（sysapproval_approver）への受信アクションもあり、「承認依頼メールに返信して承認/却下する」経路が OOTB で用意されていました。

OOTB に登録されている受信アクションの一覧

代表的な受信アクションを Name / Type / Target table で挙げると、次のとおりです。「メールで起票されない」「返信したのに動かない」を切り分けるとき、まずこの中に該当する名前があるかを探すと当たりが付きます。

• Create Incident（New / incident）

• Create Incident (Forwarded)（Forward / incident）

• Update Incident (BP)（Reply / incident）

• On-Call: Assign by Acknowledgement（Reply / incident）

• Update Problem（Reply / problem）

• Update Change（Reply / change_request）

• Update Change task（Reply / change_task）

• Update Approval Request（Reply / sysapproval_approver）

• Update Request Item（Reply / sc_req_item）

• Process CAB meeting invite replies（New / cab_attendee）

• Unsubscribe from Notification（New / cmn_notif_message）

• Create Live Feed Reply / Like Reply（Reply / live_message・live_message_like）

「何もしていないのに、メールでレコードが作られる/更新される」場合、たいていは OOTB の受信アクションが動いています。まず active な受信アクションの一覧を Type と Target table で絞って探すと当たりが付きます。

実機のフォームで見ると、Reply 型の受信アクション（既存レコードを更新する側）は次のような構成でした。

送信側 Notification との対の関係

受信アクションは、送信側の Notification（sysevent_email_action）と 対で動きます。流れで見ると次の関係です。

• 送信（Notification → sys_email） … レコードの更新などをきっかけに Notification がメールを生成します。本文末尾に watermark を埋め込んで送ります。

• 返信（利用者 → sys_email type=received） … 利用者がそのメールに返信すると、受信メールとしてインスタンスに戻ってきます。返信本文には元の watermark が残っています。

• 受信（email.read → Inbound Email Action） … 受信メールで email.read が発火します。watermark から「どの既存レコードへの返信か」が分かるため、Reply 型の受信アクションが動き、元のレコードを更新します。

「返信が新規になる」「メールが起票されない」を切り分ける

「返信したのに別の新規チケットが立った」ときは、watermark が返信メールに残っていないことを疑います。watermark が落ちると Reply と判定されず New 扱いになり、新規レコードが作られるためです。逆に「メールしたのに起票されない」ときは、New 型の受信アクションが active か、Conditions や From（送信者条件）に弾かれていないかを見ます。送信側の仕組みは別記事「Email Notification を実機で確認する」で扱っています。

ServiceNow の受信メール処理のポイント

• 受信メール処理の流れは次のとおりです。受信メール（sys_email type=received）→ email.read 発火 → 種別判定（New/Reply/Forward）→ 受信アクション（sysevent_in_email_action）実行、という順です。問題の切り分けは、この段階のどこで止まったかを見ます。

• 受信アクション（sysevent_in_email_action・ラベル Inbound Email Actions）は Business Rule に似た条件＋スクリプトのルールです。super_class は sysrule（Rule）で、送信側 Notification と同じ Rule ファミリーでした。固有フィールドは 15 です。

• Type（New/Reply/Forward）が一致するアクションだけが動きます。Reply は watermark/番号で既存レコードに紐づいた返信、Forward は転送と判定されたメール、New はそれ以外。今回の OOTB は Reply が最多（10 件）でした。

• 受信アクションは「いつ・どこに・誰の・判定・何を」の 5 軸で読みます。内訳は、いつ（Type/Execution Order）・どこに（Target table/Action type）・誰の（From/Required roles）です。加えて、判定（Conditions/Condition）・何を（Script/Field actions）があります。

• OOTB で 14 件（active 13）が登録済み。Target table は incident が最多（5 件）で、メールでの起票・更新がひと通り揃っていました。

• 「返信が新規になる」は watermark の欠落（Reply と判定されない）、「メールで起票されない」は New 型の条件/送信者条件を疑います。

受信メールを調べるときは、まず届いたメール（sys_email）を見るのか受信アクション（sysevent_in_email_action）を見るのかを切り替えます。Type（New/Reply/Forward）に応じてどの Target table のどのアクションが動くはずかを確認すると当たりが付きます。

実機で気づいたこと

• 受信アクションには stop_processing という後続処理を止めるフラグがあります。同じ Type の中で order（Execution Order）順に複数のアクションが評価される構成なので、先に一致したアクションで評価を打ち切りたい場面を想定した作りだと分かります。

• OOTB の受信アクションは、インシデント起票のような「レコード作成」だけではありませんでした。Process CAB meeting invite replies は CAB 会議の招集メールへの返信を処理し、Unsubscribe from Notification は通知の配信停止依頼をメール本文から受け付けます。メールをトリガーにする仕組みが、レコードの作成/更新以外の細かい業務にも流用されている点は、実機を見るまで気づきませんでした。

• 受信アクション（sysevent_in_email_action）自体は sysrule（Rule）を継承する「定義」ですが、受信した1通の実体である sys_email や、watermark の突合を担う sys_email_watermark は super_class を持たない独立テーブルでした。ルール（何をするか）とメール（実データ）が別系統のテーブルに分かれているのは、送信側の Notification（sysevent_email_action）とも共通する設計です。

次に読むなら

次に読むなら、受信アクションの script の書き方です（email / email_action / current オブジェクトでメール本文や送信者を読み、レコードへ反映する処理）。あわせて、Conditions と Condition script の書き分け、Forward 判定のプレフィックス設定、watermark の生成・突合の詳細も対象です。メールサーバ（POP3/IMAP）側の受信取り込みと、sys_email（type=received）から受信アクションが評価されるまでのタイミングは、本記事で範囲外とした部分です。これらは別記事で扱う予定です。送信側は別記事「ServiceNow の Email Notification を実機で確認する」を参照してください。

用語

• PDI：Personal Developer Instance（無料の検証用インスタンス）

• OOTB：Out of the Box（初期設定のまま）

• Inbound Email Action：sysevent_in_email_action テーブルの受信メール処理ルール（条件＋スクリプト）

• 受信メール：sys_email テーブルの type=received のレコード（届いた 1 通の実体）

• Type（受信種別）：受信アクションの type フィールド（New / Reply / Forward）

• Target table：受信アクションの table フィールド（作成/更新する対象テーブル）

• Action type：受信アクションの action フィールド（Record Action / Reply Email）

• watermark：通知メールに埋め込まれる識別文字列。返信を元レコードに紐づける鍵

自分の環境で確認するときのURL

先頭に自分のインスタンスを付けると、同じ画面が開けます。

受信アクション一覧(Type順)   : sysevent_in_email_action_list.do?sysparm_query=ORDERBYtype
受信アクション(Type別グループ): sysevent_in_email_action_list.do?sysparm_query=GROUPBYtype
受信メール(sys_email)        : sys_email_list.do?sysparm_query=type=received^ORDERBYDESCsys_created_on
受信アクションのフィールド    : sys_dictionary_list.do?sysparm_query=name=sysevent_in_email_action^elementISNOTEMPTY
Type の選択肢                : sys_choice_list.do?sysparm_query=name=sysevent_in_email_action^element=type^ORDERBYsequence

検証範囲とおことわり

確認した範囲（すべて PDI／Zurich／2026-06-20 確認の OOTB で取得）:

• sysevent_in_email_action の super_class（sysrule → sys_metadata）

• 固有フィールド数（15）

• 主要フィールド（前半）：type / table / action / filter_condition / condition_script / script

• 主要フィールド（後半）：template / event_name / from / required_roles / stop_processing

• Type（New/Reply/Forward・sequence順）と Action type（Record Action/Reply Email）の選択肢

• 件数（全14・active13）

• Type分布（New3/Reply10/Forward1）

• Action分布（Record Action13/Reply Email0）

• Target table分布（incident5・他各1）

• 14件すべて event_name=email.read であること

• 代表的な OOTB 受信アクションの Name/Type/Target table

確認していない範囲（これらは別記事で扱います）:

• 実際の受信メール処理フロー（本PDIに sys_email type=received は 0 件で、受信を流していない）

• New/Reply/Forward の内部判定アルゴリズムの厳密な実装

• watermark の生成・突合の詳細挙動

• 各受信アクションの script / condition_script の中身

• Reply Email アクションの返信本文

• メールサーバ（POP3/IMAP/SMTP）側の受信取り込みタイミング