> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/xsoar-6-administrator-guide/6.12/configure-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/classification-and-mapping.md). # Classification and Mapping The classification and mapping feature enables you to take the events and event information that Cortex XSOAR ingests from integrations, and classify the event as a type of Cortex XSOAR incident. For example, Cortex might generate alerts from Cortex Traps which you would classify according to the information in those events either as a dedicated Traps incident type or maybe Authentication or Malware. Also, you might have EWS configured to ingest both phishing and malware alerts which you want to classify to their respective incident types based on some information in the event. By classifying the events as different incident types, you can process them with different playbooks suited to their respective requirements. {% hint style="info" %} ### Note Classifiers and mappers can also be used for indicators. {% endhint %} **Classification** Classification determines the type of incident that is created for events ingested from a specific integration. You create a classifier and define that classifier in an integration. **Mapping** You can map the fields from your third-party integration to the fields that you defined in your incident layouts. Starting with version 6.0, mappers are separate entities from classifiers. This enables you to do the following: * Map your fields to incident types irrespective of the integration or classifier. This means that you can create a mapping before defining an instance and ingesting incidents. By doing so, when you do define an instance and apply a mapper, the incidents that come in are already mapped. * Create a default mapping for all of the fields that are common to all incident types, and then map only those fields that are specific to each incident type individually. You can still overwrite the contents of a field in the specific incident type. * Use auto-map to automatically map fields based on their naming convention. For example, severity would be mapped to importance. * Mirror content in Cortex XSOAR with third-party integrations. This enables you to make changes to an incident in Cortex XSOAR and have that change be reflected in the case managed by the integration. For example, if you are using a case management system such as JIRA or Salesforce, you can close an incident in Cortex XSOAR and have that reflected automatically.

Note

The integration must support pulling the integration schema for mirroring to work.

### **Classify Events Using a Classification Key** When an integration fetches incidents, it populates the rawJSON object in the incident object. The rawJSON object contains all of the attributes for the event. For example, source, when the event was created, the priority that was designated by the integration, and more. When classifying the event, you want to select an attribute that can determine what the event type is. {% hint style="info" %} ### Note You can also configure classifiers for indicators, by going to **Settings** → **OBJECTS SETUP** → **Indicators** → **Classification & Mapping** . {% endhint %} 1. Go to Settings → OBJECTS SETUP → Incidents → **Classification & Mapping**. 2. Click **New** and select **Incident Classifier**. 3. Under **Get data**, select from where you want to pull the information based on which you will classify the incident types. * Pull from instance - select an existing integration instance. * Select schema - when supported by the integration, this will pull all of the fields for the integration from the database from which you can select by which to classify the events. * Upload JSON - upload a formatted JSON file which includes the field by which you want to classify. 4. Under **Select Instance**, select the instance from where you want to choose the value. 5. Under **Fetched data** select the value by which you want to classify the events. 6. Drag values from the **Unmapped Values** column to the relevant incident type on the right. You can optionally choose a default incident type for unclassified incidents from **Direct unclassified events to: Select**. ![classify\_incidents.png](/files/I5hYI39TMZrloM9kF751) If you do not choose a default incident type, the classifier will use the "default" incident type for unclassified incidents. The default incident type can be configured on the Incident Types page, and is set to "Unclassified" by default. 7. Click **Save**. 8. Go to Settings → INTEGRATIONS → **Instances**. 1. Select the integration to which you want to apply the classifier. 2. In the integration settings, under **Classifier**, select the classifier you created and click **Done**. ### **Create a Mapper** Mappers enable you to map the information from incoming events to the incident or indicator layouts that you have in your system. Mapping event attributes or indicator fields now takes place in two stages. At first, you map all of the fields that are common to all incident or indicator types in the default mapping. After that, you can map the additional fields that are specific for each incident or indicator type, or overwrite the mapping that you used in the default mapping. {% hint style="info" %} ### Note In the **Classification & Mapping** screen, the mappings do not indicate for which incident types they are configured. Therefore, when creating a mapper, it is best practice to add to the mapper name the incident types the mapper is for. For example, Mail Listener - Phishing. {% endhint %} {% hint style="info" %} ### Note When mapping a list, we recommend you map to a multi select field. Short text fields do not support lists. If you do need to map a list to a short text field, add a transformer in the relevant playbook task, to split the data back into a list. {% endhint %} Be aware that the following out-of-the-box fields are entirely controlled by Cortex XSOAR, and therefore cannot be mapped: | | | | | --------------- | --------------- | ------------- | | Type | Source Instance | Category | | DBot Status | Playbook | DBot Created | | DBot Closed | SLA | DBot Modified | | DBot Total Time | Close Reason | Close User | | Close Notes | Reminder | Labels | | Run Status | Dropped Count | Linked Count | | Feed Based | | | {% hint style="info" %} ### Note You can also configure mappers for indicators, by going to **Settings** → **OBJECTS SETUP** → **Indicators** → **Classification & Mapping**. {% endhint %} 1. Go to Settings → OBJECTS SETUP → Incidents → **Classification & Mapping**. 2. Click **New** and select the mapper that you want to create. * Incident Mapper (Incoming) - maps all of the fields you are pulling from the integrations to the incident fields in your layouts * Incident Mapper (Outgoing) - maps fields from Cortex XSOAR to the fields in the integration to which you are pushing the data. This is useful for mirroring. * Indicator Mapping (Incoming) - maps all of the indicator fields to their indicator layout.

Note

For indicators ingested with a Feed Integration, indicator classification and mapping is done in the integration code and not in the Cortex XSOAR Settings > OBJECTS SETUP > Indicators > Classification & Mapping tab. For example, see the FeedUnit42v2 integration.

3. Under **Get data**, select from where you want to pull the information based on which you will map the incident types. * Pull from instance - select an existing integration instance. Select schema - when supported by the integration, this will pull all of the fields for the integration from the database. This enables you to see all of the fields for each given event type that the integration supports. * Upload JSON - upload a formatted JSON file which includes the field you want to map. 4. Under **Incident Type**, start by mapping out the **Default Mapping**. This mapping includes the fields that are common to all of the incident types and will save you time having to define these fields individually in each incident type. 5. Click the event attribute to which you want to map. You can further manipulate the field using filters and transformers. You can click **Auto Map**to automatically map fields with common or similar names to fields in Cortex XSOAR. For example, Severity to Importance or Description to Description. 6. Repeat this process for the other incident types for which this mapping is relevant. 7. Click **Save**. 8. Go to Settings → Integrations → **Instances**. 1. Select the integration to which you want to apply the mapper. 2. In the integration settings, under **Mapper**, select the classifier you created and click **Done**. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/xsoar-6-administrator-guide/6.12/configure-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/classification-and-mapping.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.