| Parameter | Description |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Alert ID** | The Alert ID received from the incoming alert payload |
| **Create Observables:** | If the **Create Observables** option is enabled, extracted observables are added to the [Observables Table](/docs/case-management/observables/observables), categorized by type (e.g., **IP addresses**, **usernames**). |
| **Link Existing Observables:** | If the **Link Existing Observables** option is enabled, the extracted observables are linked to the alert record, associating them with existing data for further investigation. |
***
## 'Extract Observables' Action Output
When the 'Extract Observables' action is executed, the output is returned in a structured JSON format. This output provides detailed information about the observable extraction process, including the following key fields:
***
## How it Works
1. **Alert Processing and Initialization**
* When a new alert is added to the [Alerts Table](/docs/case-management/alerts/alerts), its Alert ID is received, and the system retrieves its associated payload. This payload is then processed to extract key observables and its relations (if they exist) systematically, ensuring all relevant data points are captured for further analysis.
2. **Template-Based Parsing**
* Using predefined **Observable Extraction Rules** in **Case Management Settings**, the system identifies specific alert payload fields that contain observables. Each rule maps payload keys (e.g., `device.external_ip`) to their corresponding observable types (e.g., **IP Address**), ensuring structured and consistent extraction.
3. **Extraction and Validation**
* Once identified, it then verifies whether each extracted observable is valid and unique, preventing duplicates and filtering out irrelevant data.
***
## Troubleshooting Observable Extraction Action
When observable extraction action fails or produces unexpected results, it is important to understand how blink processes and maps observables based on the alert payload's data and [configured deduplication rules](/docs/case-management/blinks-automated-case-management/observable-extraction-rules) (templates).
When troubleshooting observable extraction, there are several key fields and scenarios to consider that can help you understand what went wrong:
* **Missing Template**: The action may have failed because it couldn't find a matching extraction template.
* **Invalid Template:** A template was found, but it failed to extract any observables, this typically indicates an issue with the template logic.
* **Partial Extraction** Only a subset of observables was extracted, even though the template mapping includes more. This could be due to how the data was structured or how the extraction rules were defined.
* **Duplicate Observable Content (edge case):** In some cases, an observable’s content may already exist in another observable. If so, the observable linked to the alert will retain the original observable type already associated with that content.
* **Extraction Limit (edge case)**: If there are more than `100 observables` to extract from a single alert, the system will not extract any. This is a built-in size limit.
***
### 'Extract Observables' Action – Use Case Example
***
**Step 2: Define Observable & Relations Type**
After creating the alert, the next step is extracting key observables and its relations (if applicable). Observables refer to data (such as file hashes, IP addresses, and domain names) that help security teams track malicious activity.
* **Create an [Observable Extraction Rule](/docs/case-management/blinks-automated-case-management/observable-extraction-rules) to determine:**
* **Observable Type** – In this use case example, we are extracting:
* A **Resource UID** (unique identifier of the suspicious file).
* An **IP Address** (if the file attempted to communicate externally).
* **Observable Relations** – This defines how extracted observables relate to each other and the alert:
* **whoami.rtf** (Resource UID) is linked to **FalseExecutableExtension** (alert).
* If an external connection was made, the extracted **IP Address** would be linked to both the file and the alert.
***
**Step 3: Execute the Extract Observables Action**
Once observables and observable relations (if applicable) are identified, we need to run the [Extract Observables action](/docs/case-management/blinks-automated-case-management/alert-processing/extract-observables).
* This automated action parses the alert payload, extracts observables and observable relations(if they exist), and categorizes them according to the extraction rule.
* The extracted observables and their relations are stored in the case management system for **correlation, enrichment, and further investigation**.
* Security teams can then use these observables for threat intelligence lookups, IOC (Indicator of Compromise) correlation, and automated response actions.
