Before
An operator likely reviewed incoming email requests, checked whether each request included a domain, and manually initiated the domain-blocking action when the information was present. Incomplete requests required a separate judgment or handoff before the request could be closed.
How it works
- Receive the domain-blocking request through the email trigger.
- Check whether a domain was provided and branch around the blocking action when it was missing.
- Invoke the configured domain-blocking step for valid requests and complete the workflow.
Workflow details
- Email intake: The workflow starts when an email is received through the configured email trigger, providing the event and any domain information for evaluation.
- Input validation: It checks whether the domain input is present and branches accordingly, preventing the domain-blocking action from running when the required value is missing.
- Domain-blocking action: When a domain is supplied, the workflow invokes the step named "Block Domain" through the configured FireEye Endpoint Security integration.
- Completion handling: After the blocking step finishes, the workflow marks the execution as done. Requests that fail the input check also proceed directly to completion.
- Operational result: The flow standardizes the path from an email request to domain-blocking execution while avoiding unnecessary action on incomplete requests.
What changed
Domain presence is checked automatically as soon as the email arrives, and valid requests are routed directly to the configured blocking step. Incomplete requests bypass that action and are completed through the defined alternate path.
Work removed
Reviewing each email request for a supplied domain, deciding whether the request was complete, manually initiating the domain-blocking action, and closing requests that did not contain a domain.
Expected outcome
The workflow removes up to one manual validation and one blocking handoff per email request, with incomplete requests handled consistently.
