Automations

Automations extend playbooks with automatic execution capabilities. Instead of manually running investigations, you can configure automations to execute playbooks automatically, including when ADS events trigger them.

Table of contents

• Why use Automations?
• Key concepts
• Configuring automation variables
• Execution and monitoring
• Error handling
• Event-triggered automations
• Configuring ADS integration

Why use automations?

Without automations, network analysts must manually:

• Start investigations after detecting security events.
• Track each step and intermediate result.
• Repeat the same investigation process for similar events.

With automations, you can:

• Execute playbooks automatically when specific events occur by using triggered automations, or at given intervals by using scheduled automations.
• Reduce investigation time by having results ready when you need them.
• Improve consistency by applying the same investigation methodology to similar events.
• Track progress with step-by-step execution logging.

Key concepts

• An automation executes a playbook automatically.
• Each automation step is logged with inputs, outputs, and results.
• You can re-run entire playbooks or individual steps.
• Investigation history is persisted for review.
• The investigation created by an automation is a standalone copy (not linked to a playbook).

For information about creating playbooks, refer to Playbooks.

Configuring automation variables

When you set up an automation, you must configure how the automation handles variables defined in the playbook.

Variable source options

There are three options for variable handling:

Use values from source playbook

When you select this option:

• The automation uses variable values defined in the playbook.
• If you edit the playbook later and change variable values, new investigations created by this automation will use the updated values.
• This option is useful when you want the automation to always use the current playbook configuration.

Use custom values

When you select this option:

• The automation uses custom values that you define in the automation settings.
• These values are independent of the playbook's variable values.
• Changes to the playbook's variables do not affect this automation.
• This option is useful when you want different automations to use different values from the same playbook.

Use parameter from trigger

When you select this option:

• The automation maps a playbook variable to a parameter in the trigger event.
• The variable value is taken from each incoming event at execution time.
• This option is available for event-triggered automations.
• This option is useful when event context must drive investigation values dynamically.

Example

Consider a playbook with a variable ${threshold} set to 1000:

Configuration	Behavior
Use values from source playbook	The automation uses the value 1000. If you later change the playbook threshold to 500, new investigations use 500.
Use custom values (threshold = 2000)	The automation always uses 2000, regardless of playbook changes.
Use parameter from trigger (threshold from an event field)	The automation uses the threshold value provided by each trigger event.

Execution and monitoring

When an automation runs, each step is executed sequentially with detailed logging.

Step-by-step execution

The automation engine:

1. Creates a new investigation from the playbook.
2. Configures variables according to the automation settings.
3. Executes each step in order.
4. Stores results for each step.
5. Continues to the next step or shows errors.

Monitoring execution

You can monitor automation progress by viewing the last investigation status in the automations overview table.

Re-running steps

You do not have to manually repeat investigation steps. The automation system allows you to:

• Re-run the entire playbook - Execute all steps again with the same or updated parameters.
• Re-run individual steps - Re-execute a specific step without running the entire playbook.
• Resume from failure - Continue from where the automation stopped if an error occurred.

Investigation history

All automation executions are persisted and accessible, allowing you to:

• View previous investigation results.
• Compare results across multiple executions.
• Trace how conclusions were reached.
• Share investigation results with team members.

Error handling

The automation engine provides clear error messages and step-level diagnostics when issues occur.

Step states during execution

Steps can have the following states:

State	Color	Description
Completed	Green	Step executed successfully
Selected	Blue	Currently selected step
Failed	Red	Step processing failed
Inconsistent	Orange	Result is outdated (parameters changed)

When a step fails

If a step fails during automation:

1. The automation stops at the failed step.
2. Previous successful steps retain their results.
3. You can review step-level diagnostics by clicking the failed investigation step.

Diagnosing failures

To diagnose a failed step:

1. View the error message in the step details.
2. Check the input parameters used for the step.
3. Verify that required data sources are available.
4. Review filter syntax for errors.

Recovery options

After diagnosing the issue:

• Fix and re-run - Correct the problem and re-run the failed step.
• Skip and continue - Skip the failed step and continue with remaining steps.
• Restart automation - Start the automation from the beginning with corrected parameters.

Event-triggered automations

Automations can be triggered automatically when ADS (Anomaly Detection System) detects specific events. This enables immediate, automated investigation when security anomalies occur.

Benefits of event-triggered automations

• Faster response - Investigations start immediately when events are detected, without waiting for manual intervention.
• Reduced investigation time - Results are ready by the time you review the event.
• Improved MTTR - Mean time to resolution decreases with automated initial investigation.
• Consistent methodology - Events of the same type are investigated the same way.

How event-triggered automations work

1. ADS detects an anomaly or a security event.
2. The system checks if an automation is assigned to that detection method.
3. If assigned, the automation executes the configured playbook.
4. Investigation results are available for review.

The automation creates an independent investigation, just like manual playbook execution.

Configuring ADS integration

To configure event-triggered automation, create or edit the automation in Flowmon Dashboards and Reports.

Creating an event-triggered automation

1. Go to Flowmon Dashboards and Reports > Investigations > Automations.
2. Click Create (or edit an existing automation).
3. Select the playbook to execute.
4. Select the ADS perspective and detection method that trigger the automation.
5. Configure variable handling and any additional trigger conditions.
6. Save the automation.

Integration with Response Actions

Event-triggered automations work alongside existing Response Actions:

• Automations complement but do not replace existing response actions.
• You can configure response actions in ADS and configure automation mapping in the automations form for the same detection method.
• Automations focus on investigation, while response actions focus on remediation.

Configuration options

When configuring event-triggered automation:

• ADS perspective - Which ADS perspective is used for the trigger mapping.
• Detection method - Which detection method triggers the automation.
• playbook - Which playbook to execute.
• Variable handling - Use playbook values, custom values, or parameter values from the trigger event.
• Trigger conditions - Any additional conditions for triggering.

Viewing automated investigation results

After an event-triggered automation completes:

1. The investigation is saved with results from all steps.
2. You can access the investigation from the Investigations list.
3. You can review step-by-step results and analysis.
4. You can take additional manual steps if needed.