If statements in the Blink Platform play a crucial role in controlling the flow of workflows. They evaluate conditions by comparing values, and based on these comparisons, trigger specific actions. This allows workflows to respond dynamically to different scenarios. By incorporating AND and OR logic, if statements enable more complex decision-making, as they can assess multiple conditions simultaneously, providing greater flexibility in handling various situations.
- The ‘Check If’ Icon
This icon, which appears to left of the step , verifies weather a specific condition is either true or false without running the nested actions.
The If statement: Determines the workflow’s direction based on whether a specified condition is true.
The If-Elsestatement: Determines the workflow’s direction based on whether a condition is true or false. If true, the workflow follows one course of action; if false, it follows an alternative course.
`If`- Use Case Example
The “If” statement in the use case example is being used to check whether a scanned URL is classified as “Malicious.”
The workflow is triggered when a new Gmail message is received.
The system extracts URLs from the email.
Each URL is scanned using VirusTotal (or another scanning tool).
The If statement checks if the scanned URL is flagged as “Malicious.”
If true, the workflow notifies a Slack channel and deletes the email to prevent potential threats.
If false, the workflow continues without taking these actions.
The Switch Case action allows you to compare a given value with a series of possible values and execute different blocks of actions based on the matching case value.
Flow Control Action Name
description
Switch case
The Switch Case includes a Switch Variable which is compared to a list of case values. If any of these case values matches the Switch Variable, it prompts the execution of a particular block of actions associated with that matching case value.
Case
Each Case is a value that is compared against the Switch Variable if the value of the Switch Variable matches a Case value, the corresponding block of actions associated with that will be executed
Actions
Within each case, you can choose any set of Actions to be performed.
Case Default
The default case serves as a default output option and comes into play when the Switch Variable does not match any of the other Case values.
In the provided workflow example, the Switch case action is used to implement conditional branching based on the incoming data from the Blink Web Form response trigger. It allows the workflow to take different paths depending on the value of a specified variable or condition.
The workflow starts with a Switch case action that evaluates the user input from the web form response.
Case 1: Self-Service Actions
If the web form submission indicates a self-service request, the workflow processes it by sending the request to the appropriate system and logging user feedback.
Case 2: Report an Issue
If the submission is about reporting an issue, the workflow logs the report, creates an issue in Jira, and captures user feedback.
Default Case:
If the request does not match any specific case, the workflow treats it as a general request, creates a ticket in Zendesk, and logs user feedback.
An item is an individual element in a list that is being looped through.
Accepted Values:
String
Numbers
Variable
List of JSON objects
Supported Formats:
Comma-Separated: Example: 1,2,3,4
Array Format: Example: [1,2,3,'c']
index - refers to the to variable that keeps track of the current iteration. By default the first iteration index is 0
total_items- refers to the total number of items in the list.
Debugging a Loop
In the loop action there are three distinct methods you can use to debug a loop: Run All, Run Next Item and Reset.
Note
The index in a list always starts from 0.
- 1. Run All: iterates through the entire list of items once.
If you hover over the Run All action, a tooltip will appear explaining the starting index and the index the iteration will stop at.
- 2. Run Next Item: runs the next item in the list when iterating through the list.
If you hover over the Run Next Index action, a tooltip will appear explaining the index that will run next.
- 3. Reset: resets all the changes made when applying any settings to the loop.
Advanced Settings
Start from Index allows you to start your loop at a specified index in your input list.
Stop at Index allows you to end your loop at a specified index in your input list.
Please note when using the Run All or the Run Next Item action and an advanced setting has been applied, it will continue iterating through the list based on the previous list index displayed in the output.For example, if you start the loop iteration in the middle of a list and then choose the Run All action, it won’t restart the loop from the beginning of the list. Instead, it will resume the loop from where you left off.The Start from Index and the Stop at Index advanced settings are applied in both edit mode as well as run time.
This workflow is designed to detect and respond to potentially malicious emails in Gmail. It starts when a new email arrives and extracts key details, including any URLs present in the email. The workflow then analyzes each URL to determine if it is malicious. If a malicious URL is found, the workflow takes automated response actions, such as notifying a channel and deleting the email.
A Do-while loop ensures a step or multiple steps are executed at least once. After the initial execution, it repeatedly runs the subsequent steps of for as long as the specified conditions are met.
You can enter the maximum amount of iterations you would like your While Loop or Do-while loop to carry out.
This Splunk Suspicious File Alert workflow automates threat response by analyzing potentially malicious files detected by Splunk, creating a Jira issue, and checking VirusTotal for threat intelligence. If a file has more than three malicious detections, it prompts a security analyst via Slack to decide whether to isolate the affected endpoint using Cortex XDR.
The while loop in the workflow is configured with the condition:If “malicious” is greater than 3, continue looping.
This means the workflow will repeatedly check if the number of malicious detections in the file report (from VirusTotal) exceeds 3. If this condition holds true, the loop will continue executing the steps inside it.
Inside the loop:
A Slack message is sent to ask a question.
If the answer equals “Isolate”, the endpoint is isolated using Cortex XDR.
The ‘Wait’ Action pauses the workflow for a set time before continuing to run the rest of the workflow. You can specify the wait time in seconds, minutes, or hours.
The “Wait” action will have a maximum timeout of 14 days. For more information please visit the Workflows Runtime Limitations section of our documentation.
The time value- when reached, the step is completed and the workflow will continue
Time Unit
Seconds, Minute, or Hours.
Wait for: Time Interval
This is the default mode for the Wait Action. It directs the Workflow to wait a specified amount of time until it continues running. When configuring the step, specify the number of seconds, minutes or hours to wait to wait.
Wait for: Workflow Execution
This mode enables you to wait for steps in your Workflow that execute other workflows asynchronously. The step is paused until all the executions it is waiting for, have finished running. The output of the Wait Action will return details of the executions it is waiting for.
Wait For: Web Form Response
The mode is used with the New Web Form Action to pause the workflow until a response from a user is submitted through the web form. This ensures the workflow proceeds only after the necessary input is received.
The ‘Set Variable’ action allows you to store and reuse values in different parts of your workflow, depending on how you configure it.In the following workflow use case example, we assign a variable to store the name of a Slack channel (type: string). This variable is then referenced in two actions:In the Ask a Question Via Slack action (Step 1), where it is used in the “To” parameter to specify the recipient channel.
In the Send Slack Message action (step 9), where it is reused to send a message to the same channel.
The ‘Note’ action provides a rich text editor that allows you to add helpful instructions, explanations, or contextual guidance for end-users within a Workflow. The text editor supports Markdown (md) syntax. This action is useful for adding clarity to complex workflows, ensuring users understand the next steps or any important details.
The Run - On Error action is used to handle errors that might occur during the execution of a workflow. It utilizes a dual-step structure, consisting of Run and On Error, designed to efficiently manage any errors that might arise while executing actions within the Run phase.
Run: This step is designed for placing action(s) that contributes the overall Workflow sequence.
On Error: If there is an error during Run block, the flow will automatically shift to the On Error block. In this block, specific actions are taken to address the error. The error JSON object will be made available within the On Error block to assist in handling the error.
If an error occurs in the Run block but is successfully handled in the On-Error block, the workflow will continue to run after the executing the On-Error block. However, if errors occur in both the Run’ and On-Error blocks, then the workflow will fail.
The workflow is triggered when a new user is added to a group in Okta.
It retrieves the user’s email and asks an administrator (via Slack) if they authorized the action.
If the admin denies responsibility, the workflow deactivates the user in Okta and notifies the security team.
The On Error statement is a fail-safe mechanism that catches any unexpected issues (e.g., API failures, Slack/Okta connection issues, or execution errors).
If an error occurs at any step, it sends a notification to the security group via Slack, alerting them to unusual activity.
This workflow identifies Google Drive files that are publicly accessible and enables file owners to revoke public access through a Slack prompt. If the file owner agrees to revoke access, the workflow removes the public sharing permission and ends the run with a Completed status.