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
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
Flow States
Inbound processing flows have different operational states that determine if events are handled and whether a flow can be modified.Draft
When you create a new inbound processing flow, it starts in draft state. This is the initial state for new flows where you can modify the flow configuration freely. Events are not processed by draft flows, allowing you to build your configuration without affecting live processing.Active
Once you activate a flow, it enters the active state and begins live processing of incoming events. Active flows are read-only and cannot be edited once activated. If you need to make changes, you must duplicate the configuration or start from scratch with a new flow.Draining
When you activate a new flow, the previous flow is set to draining state. In this state, Guardian Ops continues to process any remaining events from the configuration that was just replaced. The flow automatically deactivates once all remaining events are processed, ensuring no events are lost during the transition.Activating a Flow
To activate your inbound processing flow:- Complete your flow configuration in draft mode
- Save your draft
- Click the Activate button (top right)
- If there was a previous flow active, it will enter the draining state
- New events immediately use the activated flow
Once activated, flows cannot be edited. You must duplicate the configuration or start from scratch to make changes.
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.