Build an end-to-end records workflow

Bringing it all together 

Now let's build a complete workflow that demonstrates everything you've learned. You'll create a story that receives a security alert, captures it as a record, checks for previous alerts from the same user, and escalates to a case if a pattern is detected.

Before you start 

To follow along with this walkthrough, you'll need a Security Alerts record type with the following fields:

You'll also need some sample data so the workflow's escalation logic has historical records to query against. Create the following records in your Security Alerts record type:

Jane Doe has three existing alerts, so when your workflow captures a fourth and queries for previous alerts, the count will exceed two and trigger escalation. Mike Chen has only one, so his alert will follow the standard path.

Step 1: Set up the Webhook 

Create a new story and drag a Webhook action onto the storyboard. This is the entry point for incoming alerts. Name it "Receive Alert".

Step 2: Add the Capture Record tool 

Drag a Record tool onto the storyboard and connect it to the Webhook. Leave the name as is.

Configure it as follows:

• Mode: Create

• Record type: Security Alert

Map the fields:

• Alert name: <<receive_alert.body.alert_name>>

• Severity: <<receive_alert.body.severity>>

• User email: <<receive_alert.body.user_email>>

• Alert source: <<receive_alert.body.alert_source>>

• Resolved: leave blank

Step 3: Query for previous alerts 

Drag a second Record tool onto the storyboard and connect it to the Capture Record tool. Name it "Query for Previous Alerts".

Configure it as follows:

• Mode: List

• Record type: Security Alerts

• Condition: user_email is equal to <<receive_alert.body.user_email>>

This queries for all previous alerts from the same user. The results will tell your workflow whether this user has a history of triggering alerts.

Step 4: Add the Condition 

Drag a Condition action onto the storyboard and connect it to the List Record tool. Name it "Existing user alert?"

Configure the rule to escalate:

• <<SIZE(query_for_previous_alerts.records)>> is greater than 2

If the user has more than two previous alerts, the workflow escalates. Otherwise, it follows the standard path.

Step 5: Create a case on escalation 

On the "escalate" path, drag a Case tool onto the storyboard and connect it to the Condition's match rule. Leave the name as is.

Configure:

• Case name: <<receive_alert.body.alert_name>>

• Priority: High

• Records: <<capture_record.id>>

• Status: To do

Step 6: Log the standard path 

On the standard path (no match), drag an Event Transform action onto the storyboard and connect it to the Condition's no match rule.

Configure it as follows:

• Mode: Message only

• Message: "Alert processed, no escalation required."

Step 7: Test your workflow 

That completes the story. Now it's time to test.

Using the HTTP Request action from the tip in Step 1, send the following payload. In our sample data set, Jane Doe already has multiple alerts, so the List query will return more than two results and the Condition will escalate.

{
  "alert_name": "Unauthorized access to admin panel",
  "severity": "Critical",
  "user_email": "jane.doe@example.com",
  "alert_source": "Crowdstrike"
}

After sending, verify that:

• A new record appears in the Security Alerts records table.

• A high priority case was created with the attached record.

Now send a second payload. In our sample data set, Mike Chen has only one previous alert, so the Condition will take the standard path.

{
  "alert_name": "Failed login attempt",
  "severity": "Low",
  "user_email": "mike.chen@example.com",
  "alert_source": "Sentinel"
}

After sending, verify that:

• A new record appears in the Security Alerts records table.

• No case was created.

• The Event Transform action logged "Alert processed, no escalation required."