> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blinkops.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Alert Processing Completed

> Trigger a workflow automatically when a case's alert finishes processing and the case is ready to investigate in Blink case management.

This trigger runs a workflow for every case whose investigation status changes to `Ready to Investigate`. That status marks the point where the alert that opened the case has finished processing, with its observables extracted and enriched.

Each event is the case that became ready.

<Note>
  **Note**: The workflow that processes alerts is what sets the status, once enrichment has finished. That is a stronger signal than the alert's own `processing_status`, which turns `Processed` during deduplication, before enrichment has run.
</Note>

<Note>
  **Note**: For `long-text` fields (e.g., `Summary`), the returned value will be a substring of the full content. To obtain the complete value, retrieve the entire case.
</Note>

<Note>
  **Note**: Workflows based on this trigger will search for new events **every minute**.
</Note>

## Sample Event

```json theme={"dark"}
{
	"alert_ids": null,
	"attachment_ids": null,
	"auto_id": 10635,
	"case_id": "INC-10635",
	"case_ids": null,
	"case_manager": null,
	"case_tags": null,
	"close_reason": null,
	"closed_at": null,
	"closed_by": null,
	"closed_by_automation": false,
	"collaborators": null,
	"created_at": 1732194432630,
	"created_by": "test@blinkops.com",
	"id": "bb2a5fcc-423b-4536-8b7a-63a547216579",
	"investigation_status": "Ready to Investigate",
	"ioc_ids": null,
	"mitre_attack": null,
	"name": "New Case",
	"observable_ids": null,
	"overview": null,
	"severity": 1,
	"sla": null,
	"sla_expiry": null,
	"status": "OPEN",
	"summary": null,
	"task_ids": null,
	"test": null,
	"type": null,
	"updated_at": 1732194441635,
	"updated_by": "test@blinkops.com",
	"vendors": null
}
```

## Testing Workflows Triggered by a Case Event

When building a workflow triggered by a case event, the testing parameters include a "Fetch event" button. This button retrieves a recent case ID for testing purposes.

However, it's important to note that the returned case ID may reference a case that has been deleted since the last polling interval. This behavior is expected and by design.

As a result, the fetched ID may not always return valid case data when used in subsequent steps.

**Recommendation:**
Builders should account for this scenario by implementing appropriate error handling in their workflows to manage cases where the retrieved ID is no longer valid.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.