Skip to main content
Inbound processing allows you to control which events reach Guardian Ops and how they should be enriched. The flow also determines how events and their associated cases are grouped into case groups, if configured.

​
Overview

The core feature of inbound processing is the inbound flow. Guardian Ops provides different nodes that you can use to customize your processing workflow.

​
Available Nodes

The following nodes are available for building your inbound processing flow:
  • Delay - Add time delays in processing
  • True/False - Conditional logic branching
  • Tags - Apply tags to events
  • Resolution - Customer resolution logic
  • Case Group - Group events into cases
  • Drop Event - Remove events your abuse desk ignores
  • Divider - to document and comment within complex workflows
For detailed information about each node, see the Node Reference.
Inbound Processing Nodes

​
Flow Structure

Inbound processing starts with an empty graph containing:
  • Starting node: “Incoming Events” - Entry point for all incoming events
  • Ending node: “Unassigned Events” - Destination for unprocessed events
Inbound Processing Empty Flow See the Unassigned Events section below for more details on unassigned events.

​
Flow States

Inbound processing flows have different operational states that determine if events are handled and whether a flow can be modified. Only one inbound processing flow version can be active at a time. For detailed information about flow states (Draft, Active, and Draining), see the Flow States reference.

​
Activating a Flow

To activate your inbound processing flow, complete your configuration in draft mode, save your draft, and click the Activate button. When you activate a new flow, the previous flow (if any) enters the draining state to ensure no events are lost during the transition. For detailed activation instructions and best practices, see Flow States.

​
Unassigned Events

All events that don’t match your filters and rules in inbound processing end up in the unassigned section. This section contains events that caused processing errors, remain unresolved after processing, or don’t match any branches that end up in a case group in your inbound processing flow.

​
Common Causes

Unresolved events typically occur when your resolver API returns an error or when no matching customer is found in your database. If you only have an IP resolver configured, it may happen that Guardian Ops cannot resolve a domain to an IP address in a domain-related abuse event, which means no customer ID is present and therefore the event is considered unresolved.

​
Managing Unassigned Events

You can handle unassigned events in two ways. The recommended approach is to update your inbound processing flow by incorporating these events into your rule set. Alternatively, you can explicitly drop events that should not be processed using drop nodes in your flow. To keep things tidy, you can delete unassigned events. View the unassigned events section in Guardian Ops.

​
Examples

  • Minimal Flow
  • Conditional Flow
  • Advanced Flow (+API Resolver)
The minimal inbound processing flow required to fill the Customers view. The IP Resolver resolves the IP as a customer ID.Minimal Inbound Processing Flow with IP ResolverThis basic example shows events entering through the incoming events node, being processed by an IP resolver to identify customers (assign abusive IP as customer ID). This will only populate the customers view as no case groups are configured in the flow.