Field Mappings
LAST UPDATED: JULY 28, 2025

Third-party vendors provide semantically distinct entities—such as events, incidents, and alerts—using varied JSON structures and key names. To normalize inter-vendor and payload heterogeneity for streamlined processing and operational support, raw JSON keys containing relevant event- or incident-related information are reassigned to D3 data model or user-defined field names. This key reassignment process is known as field mapping.
IFM and EFM in the Data Pipeline
Field Mapping Types
There are two field mapping types: Incident Field Mapping (IFM) for incident-level data and Event Field Mapping (EFM) for event-level data. Both occur in the post-ingestion processing pipeline, which varies slightly based on the integration fetch command used.

Fetch commands are of two main types:
Fetch Incident – Applies both incident field mappings and event field mappings.
Fetch Event – Applies only event field mappings.
Source Field as Individual Mappings
A source field is a relative JSONPath expression used in EFM and IFM to reference a specific field within the raw JSON payload. The source field begins at the array defined by the Main JSON Path (IFM) or Main Event JSON Path (EFM), and traverses deeper into the JSON structure to reach the desired key.

See Source Field — Supported JSONPath Expressions for syntax details.
Source Resolution
Each event or incident source defines how data for a vendor-specific entity type should be interpreted and normalized. In D3, source is implemented as an integration-specific, named configuration that links to an EFM or IFM set. To apply the correct set, D3 must resolve each object within the array defined by the Main (Event) JSON Path to a specific source.
The Main Event JSON Path points to an array, with each object evaluated against configured EFM sources. The Main JSON Path also points to an array, with each object evaluated against configured IFM sources and potentially containing a nested array referenced by the Main Event JSON Path. A source's applicability is determined by a search string, which may be built-in or user-defined.
Search Strings
Each non-default source involves a search string that determines its applicability during source resolution. A search string evaluates data within the Main (Event) JSON Path to determine whether a specific key exists and whether its value matches the configured value. When a key-value pair in the payload matches a configured search string, the corresponding EFM or IFM set is used to normalize the third-party data.
The search string must adhere to one of the following formats:
FORMAT 1
{<Descriminator JSONPath>}=<Discriminator's literal value without quotes>
FORMAT 2
{<Descriminator JSONPath>}={{<Regular expression matching discriminator's value>}}
Order Priority
When search strings from different sources simultaneously match different key-value pairs in the ingested JSON payload, the Order Priority field determines which match takes precedence.

The (Default Event Source) mappings apply regardless of Order Priority.
Only one non-default event source applies per post-ingestion pipeline execution.
Search strings from multiple event sources may match fields within the same payload.
The source with the lower Order Priority takes precedence.
If priorities are equal, the source created first takes precedence.