These are the types of triggers:

• Event: The workflow is triggered by an event in the Falcon environment.

• Schedule: The workflow is triggered regularly, based on a defined schedule, such as hourly, daily, weekly, or monthly.

  Also, you can run this type of workflow immediately through the Falcon console or an API call, as shown in Run a workflow on demand.

• On demand: The workflow is triggered directly through the Falcon console, by another workflow, or by an API call, as shown in Run a workflow on demand.

• Inbound webhook: The workflow generates a unique webhook URL for the given workflow and is then triggered by an external system that uses that URL. For more info, see Custom triggers based on inbound webhooks and Create and manage triggers based on inbound webhooks.

The event triggers available depend on your subscriptions.

You can look for triggers in the content library as explained in Library of actions, apps, Foundry app templates, playbooks, and triggers or read this overview of the trigger categories.

• 3PI Data Connection: For more info, see Data Connectors.

• Detection: Falcon reports on these detection types:

  • EPP Detection: For more info, see Endpoint Detection Monitoring.

  • Identity Detection: For more info, see Identity-based Incidents, Detections, and Risks.

  • Mobile detection: For more info, see Configuring Falcon for Mobile.

  • Next-Gen SIEM Detection: For more info, see Detection Monitoring.

  • Next-Gen SIEM Case: For more info, see Cases.

  • Third Party Detection: For more info, see Third-party detections.

  • Data Protection Detection: For more info, see Data in Motion.
• Asset management: Falcon reports a change to an asset, including new assets seen in your environment, applications being installed or uninstalled, system resources reaching certain levels, and more. For more info, see Asset Management: Assets, Asset Management: Applications, or Manage External Assets.

• Audit event: Trigger a workflow on any of these changes:

  • Policy (Prevention, Firewall, Sensor Update, Device Control, Response, Mobile, Identity Protection, and Airlock policies)

    • Deleted

    • Created

    • Enabled

    • Disabled

    • Updated

  • Host

    • Host unhidden

    • Host containment lifted

    • Host hidden

    • Request to lift containment

    • Containment requested

    • Host contained

    Note: If you include the Host Group attribute in a notification generated with one of these triggers, the Host Group ID appears in the notification, rather than the Host Group name.

  • Detection

    • Tag

    • Comment

    • Assignment

    • Status

    • Severity
  • General settings
    • Channel file update controls
  • RTR Session
    • Session end
    • Session start
  • XIoT event
    • Collection
    • Schedule

• Cloud security assessment: Falcon reports a new cloud security finding

• Custom IOA monitor: Falcon reports a custom IOA detection. For more info, see Monitor custom IOA detections and preventions.

• Device Control: Trigger a workflow for any of these events:

  • Removable storage, USB, or Bluetooth:

    • connected events

    • blocked events

    • policy violation events

  • Files written to removable storage

  Note: Bluetooth events are only supported for macOS.

  For more info, see Device Control.

• FileVantage change: Falcon reports a file integrity change. For more info, see Falcon FileVantage.

• Host state: Trigger a workflow when a host enters one of these states:
  • Provisioning
    • Host fully provisioned: When a host has downloaded all available channel files
  • Support
    • Host in Reduced Functionality Mode (RFM): When a sensor has entered RFM
  • Visibility
    • Host connect: When a host has connected to the cloud
    • Host first seen: When a host is seen on Falcon for the first time
  Note: If you include the Host Group attribute in a notification generated with one of these triggers, the Host Group ID appears in the notification, rather than the Host Group name.
• Identity account event: Falcon reports an Identity account event, for example, a compromised password.

• Kubernetes and containers: Falcon reports a security finding related to your Kubernetes environment or containers in your cloud environment. This includes vulnerabilities and detections identified by the Image Assessment tool, container runtime detections, container drift detections, and detections triggered by Image Assessment prevention policies. For more info, see Container Security.

• Phishing email: Trigger a standardized response to user-reported phishing emails connected through the supported email service. For more info, see the CrowdStrike Store app Microsoft 365: Email Phishing Plugin or GMail Phishing Plugin.
• Receive email: Emit events when new emails arrive in shared or dedicated inboxes connected through the Microsoft 365: Monitored Mailbox Connector. This trigger allows you to start additional workflows, extract indicators, correlate data across sources, process attachment files, and collect user input. For more info, see the CrowdStrike Store app Microsoft 365: Monitored Mailbox Connector.
• Serverless functions: Findings from serverless functions scans.

• Vulnerabilities user action: A vulnerability management user selects Create ticket for a vulnerability, host, or remediation. For more info, see Vulnerability Management Ticketing Workflows.

• Workflow execution: Trigger a workflow off of a workflow. This option is useful if you want to set up notifications to know when workflows run or hit a failure point.

  Note: In Flight Control environments, using this trigger makes the workflow execution customer ID available, which indicates the CID where the workflow executed and can be either the parent CID or the child CID.
• Zero Trust Assessment: Trigger a workflow based on Zero Trust Assessment (ZTA), such as a change in a host’s assessment score or if a host fails a specific assessment. For more info, see Zero Trust Assessment.

• Message Center: Falcon Message Center has a new case, update, or comment. For more info, see Message Center.

Fusion SOAR provides many triggers to start your workflows. However, you can also create custom triggers that use inbound webhooks to integrate third-party tools, enabling real-time orchestration from those tools. For example, you can define triggers for events from external sources such as SIEMs, SOAR platforms, ticketing systems, and threat intelligence feeds.

For info about requirements for these triggers related to subscriptions, CrowdStrike clouds, and roles, see Requirements.

For info about how to manage these actions, see Create and manage triggers based on inbound webhooks.

You can use multiple workflow conditions joined with AND operators or OR operators to create complex logic in your workflows.

• With AND operators, the overall workflow condition evaluates to true only if all included conditions are true.
• With OR operators, the overall workflow condition evaluates to true if any one or more conditions are true.

For example, this sample workflow sends a notification by email when an endpoint detection is high severity and associated with a sensor platform of Windows. Both conditions must evaluate to true for the workflow to send the email.

For a more complex example, this sample workflow sends a notification by email when any one of several detections or preventions take place in Falcon Prevent: a detection occurs, a prevention kills a process, a file is quarantined, a combined action of killing a process and quarantining a file, or a process would have been killed but a policy setting was not enabled. You could create individual workflows or ELSE IF operators for each of these items, but using an OR operator can be simpler for your analysts to understand at a glance.

Conditions include several operators that vary depending on the selected parameter:

• is equal to

• is not equal to

• is greater than

• is less than

• is greater than or equal to

• is less than or equal to

• exists

• does not exist

• includes

• does not include

• matches

• does not match

In Fusion SOAR conditions, you can use operators such as is equal to and exists to examine a parameter and possibly a literal, or static, value. In addition, you can use functions to transform data and write more expressive conditions. For example, you can determine whether an IP address is v4 or v6 with these expressions:

size(data[source.ips]) > 0

To use these expressions, when creating or editing a condition, click Advanced mode.

With this feature, you can also compare variables. For example, you can compare an IP address from event search results with one retrieved for a particular host.

You can also use the Charlotte AI Data Transformation Agent to help you create complex CEL expressions without needing to learn the syntax. Use the expression builder to tell Charlotte AI what you want to accomplish with your data. Charlotte AI interprets your request and creates the appropriate CEL expression to meet your needs.

For more info about the functions you can use in expressions, see Fusion SOAR Data Transformation Functions.

You can find the actions when searching in several ways:

• By the action name

• By words in the action descriptions

When you search, the most relevant results are shown in the Top results section. After that, all of the results are shown in lists.

Before and after searching, you can refine the search by filtering. To see the options, click Filter. These are the options:

• Hide unavailable actions

  Show all the actions or just the ones that make sense in the current context by enabling or disabling Hide unavailable actions. Actions might be unavailable because of a missing prerequisite, plugin, or permissions. Showing all actions allows you to see the possibilities if you are able to resolve the requirements.

• Group by

  Group the actions by vendor to show only the actions relevant to the given vendor.

  Group actions by use case, such as Endpoint security or Identity & Access, which shows all the actions relevant to the given use case.

• Vendor

  Select specific vendors to show only the actions relevant to those vendors.

After you find an action, complete these steps to add the action to your workflow:

1. Click the action.

2. Optional. Check what input the action requires by clicking View schema and then Input schema.

   For more info about JSON schema, see Manage action input, action output, and on-demand triggers.

3. Check the output so you know what to expect from the command by clicking Output schema.

4. Configure the action.

5. Click Test action to verify the action works as expected, without running the entire workflow. For more info about unit testing, see Test an action.

6. Click Next.

If you create any actions—such as actions based on event queries or in Foundry apps, these actions go in the group named Other (Custom, Foundry, etc.).

You can use many of the actions you find in the console without additional info. However, some of them have usage details that aren’t obvious. This list provides more info about those actions:

• Enrichment: Incorporate device or third-party vendor data for enriched context

  • Get customer details: This action is available only in parent CIDs in Flight Control environments.

• Real time response: Execute Real Time Response commands

  Note: For info about enabling multifactor authentication for workflows with RTR actions, see Real Time Response (RTR).
  Tip: Review details about executed RTR commands at Audit logs > Audit logs > RTR .

  • Execute commands aligned with your RTR role:

    • Get file (get)

      • Retrieves host files.

    • Kill process (kill)

      • Takes a process ID as input and stops the process from running.

      • A common subsequent RTR command workflow action is Remove file.

    • Process memory dump (memdump)

      • Available with Windows only.

      • Requires a condition that specifies the sensor platform is equal to Windows. For more info, see Workflow conditions.

      • Takes a process ID as input.

      • Output is the local file path of the memory dump file saved on the host.

      • Common subsequent RTR command workflow actions include:

        • Get file then Remove file

        • Kill process then Remove file

    • Put file (put)

      • Available with Windows, Mac, and Linux only

      • Requires a condition that specifies the sensor platform is equal to Windows, Mac, or Linux. For more info, see Workflow conditions.

      • Takes an executable file name from the list of “PUT” files uploaded to Host setup and management > Response and containment > Response scripts and files.

      • A destination path that specifies where to download the file must be provided.

    • Put and run file (put-and-run)

      • Available with Windows and Mac only

      • Requires a condition that specifies the sensor platform is equal to Windows or Mac. For more info, see Workflow conditions.

      • Takes an executable file name from the list of “PUT” files uploaded to Host setup and management > Response scripts and files.

      • Supports optional command line parameters that are passed when the file runs.

    • Remove file (rm)

      Note: You can't rm actively running executables or protected system files, such as anything under C:\windows\system32.

      Attempts to do so produce a failed workflow action and this error: Access to the path is deniedTo improve workflow efficacy:

      • Set up other workflow actions to run in parallel as the rm action.

      • Avoid setting up critical actions after an rm action. If the rm action fails, subsequent actions are skipped.

    • Retrieve active network connections (netstat)

    • Retrieve running processes (ps)

    • Run file (run)

      • Takes the file provided in the trigger event as input. For more info, see Workflow triggers.

      • Supports optional command line parameters that are passed when the file runs.

  • Execute Falcon scripts.

    • Select the script name, and then provide arguments as required.

    • Available with Windows only.

    • Requires a condition that specifies the sensor platform is equal to Windows. See Workflow conditions.

    • Only users with the RTR Administrator role can add Falcon script actions to workflows.

  • Execute RTR custom scripts. For more info, see Managing custom response scripts.

    Note: Only users with the RTR Administrator role can add custom-script actions to workflows.

• Identity Protection: For example use cases for the following Identity Protection workflow actions, see Identity Protection in Fusion SOAR.

  • Watch or unwatch users and endpoints

    Endpoints must be in an Active Directory domain monitored by Identity Protection. CrowdStrike recommends adding a condition that filters out non-Windows platforms before adding this action to a workflow. For more info, see Workflow conditions.

  • MFA challenge
  • Active Directory actions
    • Reset user Active Directory password
    • Active Directory - Enable Account
    • Active Directory - Disable Account
    • Active Directory - Unlock User
  • Get additional user or endpoint context from Falcon Identity Protection.
    • Get user identity context
      • This action provides identity context for a given user identifier. There are a number of available identifiers that you can use based on the trigger, including:
        • User object SID
        • User name
        • User object SID
        Note: This action executes a query that searches for an entity which matches all fields with the OR condition. Therefore, we recommend that you select only one identifier to use in your workflow.
      • This action returns information from Identity about the user such as risk severity, privileges, group membership, and so on. This info can be used in further conditions in your workflow.
    • Get endpoint identity context
      • This action provides identity context for a given entity. There are a number of available identifiers that you can use based on the trigger, including:
        • Endpoint SID
        • Endpoint object GUID
        • Sensor ID
        • Endpoint name
        Note: This action executes a query that searches for an entity which matches all fields with the OR condition. Therefore, we recommend that you select only one identifier to use in your workflow.
      • This action returns information from Identity about the endpoint such as risk severity, classification, group membership, and so on. This info can be used in further conditions in your workflow.
  • Entra ID response actions
    Note: The CrowdStrike Store Microsoft Entra ID SOAR Actions plugin must be configured for this action to appear. For more info, see Integrate with Microsoft Entra ID.
    • Entra ID - Add User to Group
    • Entra ID - Disable User
    • Entra ID - Enable User
    • Entra ID - Remove User from Group
    • Entra ID - Revoke Existing Refresh Tokens
    • Entra ID - Revoke Existing Sign-in Sessions
    • Entra ID - Mark User as Risky (requires Microsoft Entra ID P2 license)
    • Entra ID - Unmark User as Risky (requires Microsoft Entra ID P2 license)

• Event search: Run an event search to gather data for actions or triggers.

  For example, you could find users logged in during the last day. Check each user against the Identity Protection watchlist. Then, for the users on the watchlist, send the users email to notify them that their systems will be contained, and then contain the systems. Alternatively, when a detection occurs, you could get the process associated with the detection and find all network connections associated with that process. Then add this info to a report and distribute it in an email.

  Note: These actions require the Falcon Insight XDR subscription.

  After the event search action runs, the results are available to use in an action or condition. The results vary based on the search action. To get the results when you are defining an action that accepts a file, such as the Create Jira issue action, in the Data to include list, find the name of the event search action. To get the results when you are defining a condition, in the Parameter list, find the name of the event search action. For example, for the condition shown below, under the name of the event search action, Retrieve executed processes, the only option to access the results is Unformatted results. Another you might see is Full results download URL.

  
  
  
  Tip: To expose fields from the results one at a time, use the results in a loop. For example, using the Find logins for a user account across all hosts search returns a list that includes the systems where the user is logged in. You can then loop over the results and perform actions for each of those systems. When defining the loop, in the Input source list, find the name of the event search action. Related playbooks:

  • Identity Protection Watchlist Update after Credential Access Detection: Automatically adds users and hosts to the Falcon Identity Protection watchlist in response to identity-based incidents that use MITRE ATT&CK® Credential Access tactics.

  • ServiceNow Ticket Creation for High Severity Detections: Creates ServiceNow ticket for high severity detections with recent executed processes and command line history attached to the ticket.

  Note: An event search action times out if it runs more than 1800 seconds, which is 30 minutes. The workflow execution fails with the timeout.

• Call webhook: Send an HTTP request to a webhook URL

  The Call webhook action supports customizable input through its Custom JSON field. This support provides flexibility in exporting and managing data by allowing you to define a mapping to tailor data to the downstream tool processing the webhook.

  When you add a Call webhook action, you have these Data format options for the data to export:

  • Default

    Displays the Data to include list that allows you to select multiple items to use.

  • Custom JSON

    Displays a field where you enter your JSON to map Falcon data to the desired custom JSON format. To help you map data to the desired fields, click Workflow data and then copy and paste variables.

    For example, you can create a simple mapping of data to the desired property names.

    

    As another example, you can map data by category. Here we have two categories: One for detection data and one for workflow data.

    

• Sleep: Wait a specified time before proceeding to the next action

  Note: When a trigger occurs, status and all other info is permanently set. Using a Sleep action in a workflow to wait for any of the trigger info to change does not work because that info never changes.
• Next-Gen SIEM actions: With Next-Gen SIEM, several actions are available to use third-party data. However, the following actions are not available in US-GOV-1 or US-GOV-2:

  • Darkfeed

  • Falcon for Mobile built for Microsoft Intune

  • IPQS Threat & Risk Scoring

  • Iris Threat Intelligence

  • Rubrik Security Cloud

  • SecurityScorecard Cyber Risk Ratings

  • VirusTotal

• Loop types

  • For each: Iterate over a defined dataset concurrently or sequentially until the dataset is used–or a Loop break action occurs.

  • While: Iterate sequentially over loop-scoped data until a specified condition is met or a Loop break action occurs.

    Tip: In addition to defining a condition using the Parameter and Operator dropdown lists, you can define a condition using an expression with a data transformation function. Using these expressions, you can transform data and write more expressive conditions. To use these expressions, when creating or editing a condition, turn on Advanced mode. For more info about the functions you can use in these expressions, see Fusion SOAR Data Transformation Functions.

    With this loop type, you also have the option to end a loop based on the number of iterations and time in the loop.

    Important: Most parameters you set in a While condition are not updated with each iteration. To use those parameters:

    1. Create a custom variable that you set to the value of the desired parameter before the loop. Use the Create variable action.

    2. Use that custom variable as the parameter in the While condition.

    3. Update the value of the custom variable inside the loop to match the current value of the desired parameter. Use the Update variable action.

• Processing orders

  • At the same time / concurrently

    • Available only to For each loops.

    • Runs iterations in batches of 500 with the iterations run at the same time. Batches run one at a time. The batch size is subject to change.

    • Concurrent loops do not output data that you can directly use in subsequent actions or loops, however you can use the Write to log repo action to retain the output.

    • Any custom variable updated in a concurrent loop doesn't retain the update after the loop iteration

  • One after the other / sequentially

    • Available to For each loops and While loops.

    • Runs each iteration in order.

    • Loops end when all iterations are complete or a Loop break action occurs.

      While loops can also end based on a condition, the number of iterations, and time in the loop.

    • Sequential loops output data arrays that you can use in subsequent actions or loops.

    • Any custom variable updated in a sequential loop retains the update made in the last loop iteration

• Nested loops

  • A loop within a loop is a nested loop. Nesting only goes one level: Nested loops can’t contain loops.

  • A loop can have one or more loops nested in it. With multiple nested loops, the loops must be on different branches and loop on different items.

• Related actions

  • Loop break

    Use this action after a condition to possibly end the loop.

    Note: This action is available only for loops with sequential iterations.

    When you use this action within a nested loop, specify whether to end the parent loop or the grandparent loop.

  • Create variable

    Use this action to create a variable.

    Note: Use integer variables whenever comparing whole numbers. Don't use integer variables as input in action fields.

  • Update variable

    Use this action to update a variable inside a loop.

    Note: For a loop with sequential iterations, variables are available outside the loops and have the value set in the last loop iteration. For a loop with concurrent iterations, you can update and use variables inside the loop; however, the values set in the loop are not retained for use after the loop.

• Output availability

  • You can make the output of actions in a sequential loop available to use later in the workflow.

    The End Loop item identifies the loop's output.

    The output is an array of objects, where each object corresponds to an iteration of the loop and each field corresponds to a chosen loop output key. You can then use the entire array or its separate fields in other parts of the workflow.

    Important: In the output, some fields might be empty if conditions in the loop create branches and those branches use actions that populate different fields.
  • To retain the output for a concurrent loop, use the Write to log repo action.

  • In a loop with multiple actions, the output from each action is only available to subsequent actions in that loop. For example, the second action can use the output of the first action. However, the first action can’t use the output of the second action.

  • The output of an action not in a loop is available to any actions that come after it on the same branch.

• Default iteration limits

  To prevent indefinite loops when you use a While loop or a For each loop with sequential processing, loops have a default limit of running for 50 iterations or 60 minutes–whichever comes first. To adjust these values, select the Limit iterations option and enter your desired values.

A loop can run, or iterate, up to 100,000 times. If a loop attempts to iterate more than 100,000 times, both the loop and its workflow go into an error state. Such a workflow is not available to retry. See Retry a failed execution. To continue a workflow even when a loop fails, use the Continue workflow on loop iteration failure option when you create loops. See Loop iteration failure.

With nested loops, both the outer loop and the nested loop can iterate up to 100,000 times each.

In concurrent loops, loop iterations are processed in batches, one batch at a time. As a result, larger loops can take hours to complete.

In both concurrent and sequential loops, the amount of time for a workflow to complete depends on the number of actions in each loop and, if those actions aren’t completed quickly enough, the timeouts for those actions.

To reduce a workflow’s execution time, decrease the amount of work in each loop.

Consider loops A, B, and C.

Loops A and C are parallel:

• They run at the same time.

• There is no dependency between the loops. If loop A fails, loop C still runs.

• The output of any actions in loop A is not available in loop C.

• The output of any actions in loop C is not available in loop A.

Loops A and B are sequential:

• Loop A must finish before loop B can start.

• If loop A fails, loop B might not start—depending on the Continue workflow on loop iteration failure option. For more info, see Loop iteration failure.

• The output of any actions in loop A is not available in loop B.

The possibilities for looping are numerous. Here are examples to give you some ideas about those possibilities.

In concurrent loops, a loop tries to run for each item of input, up to a maximum of 100,000 iterations. If any of those iterations does not complete successfully, the workflow behavior depends on the Continue workflow on loop iteration failure option. This option is available to select only when you define a concurrent loop.

Be aware of these limitations:

• You can only query repositories that CrowdStrike provides. Querying data sources you host is not possible.

• While the email action available in Fusion SOAR does allow you to append query results to the message body, the results are limited to 5000 characters and in JSON.

  However, you can attach a file that is up to 10 MB in size.

• Search actions are available only in the CIDs where they were created.

• By default, query results are limited to 200 rows.

  You can increase this limit to 10,000 rows by specifying a tail in the query. To specify a tail, pipe the query to tail(x):

  | tail(x)

  where 200 < x <= 10000.

  Similarly, you can pipe a query to head(x).

• The query result supports only primitive types–that is, types that represent a single value.

  For example, {key: foo} is supported, but {key: [foo, bar]} is not.

• An action based on an event query times out if it runs more than 1800 seconds, which is 30 minutes. The workflow execution fails with the timeout.
• Event queries are workflow-specific or CID-specific. Use workflow-specific queries if you want to import a workflow in other CIDs.

Review how endpoint detections have been assigned to your users, tagged, and moved through statuses to identify what actions you might want to automate.

• Review how your organization has remediated incidents and detections in the past to establish which kinds of actions you might want to automate on specific kinds of detections.

• It’s essential that you craft workflows that involve remediation with specific conditions to avoid taking action on a large number of hosts.

• Consider creating or updating RTR custom scripts. Custom scripts with the Share with workflows toggle enabled are available as RTR actions in workflows. For more info, see Managing custom response scripts.

• Ensure your Response Policies, set using Host setup and management > Response and containment > Response policies, are configured to allow the actions you’re expecting from your workflows.

• You can enable additional security by going to Support and resources > Resources and tools > General settings . In the Security menu, select Re-authentication for critical actions, and then enable these settings:

  • Real Time Response (RTR) identity verification

  • Before enabling a Fusion SOAR workflow with any RTR action

  With these settings enabled, if a workflow has an RTR action, when you enable that workflow or run it on demand, Fusion SOAR prompts you to verify your identity using multifactor authentication, or MFA.

See Set up VirusTotal integration.

• Think about what notifications you want to set up and review your existing Falcon notifications, noting potential crossover that might create duplicate notifications for your users.

• Carefully consider what people in your organization need to know about and the best way to reach them. Be precise about what triggers notifications and who receives them so you don’t fire off too many for your users to handle.

• Set up plugin integrations for notification channels, if needed:

  • Jira

  • Microsoft Teams

  • PagerDuty

  • ServiceNow

    Tip: When you create a workflow, refer to Creating ServiceNow incidents with host details or Vulnerability Management Ticketing Workflows.

  • Slack

  • Webhook

You can trigger workflows for unmanaged assets, unsupported assets, and new external assets using an asset management trigger.

• Triage unmanaged and unsupported assets. These are assets that don't have the Falcon sensor installed.

  • Think about how best to determine whether assets new to your environment belong there and which conditions typically inform those decisions.
  • Carefully consider the conditions and triage actions to decide which ones you might want to automate, such as when to recommend a sensor install on an unmanaged asset, or to change an unmanaged asset to unsupported.
    Note: Any workflows that include the Move to unsupported or Move to unmanaged action must also include a condition that specifies the Entity type as either Unmanaged or Unsupported or else the workflow won't be completed.
• Trigger a workflow when new external assets are added to your ecosystem.

Asset actions aren't available in CrowdStrike government clouds.

When editing an action, you can test it without running the entire workflow. This is known as a unit test.

To find your Fusion SOAR workflows, go to Fusion SOAR > Fusion SOAR > Workflows .

If you are creating or editing a workflow, you can navigate the workflow canvas several ways.

To move the workflow within the canvas, click and hold a spot in the canvas, and then drag it.

To zoom in or out on a particular spot in a workflow, hover over that spot and use your mouse's scroll wheel.

To edit an item, click it and, depending on the item, click Edit or Back .

To see options to delete an item or to add more items immediately after it, hover over the item.

Also, you can select items in the workflow by using the Tab key.

When tabbing, press Enter to act on the selected item. Within a workflow, pressing Enter could show details for the item and allow you to edit it, delete the item, or present items you can add after the current item. Consider these scenarios:

• If pressing Tab selects an action item, pressing Enter displays the panel where you can edit the action.

• If pressing Tab selects , pressing Enter deletes the item.

• If pressing Tab selects , , or at the bottom of an item, pressing Enter shows the items you could add at that point.

Outside a workflow, tabbing provides access to the menu bar, where you also press Enter to act on the selected item.

1. Go to Fusion SOAR > Fusion SOAR > Workflows .

2. Click Create workflow.

3. For Flight Control environments, users with the Falcon Administrator role in the parent CID can choose which child CIDs the workflow applies to. Those workflows can trigger for any child CID, even if the users don’t have permissions in the child CIDs. However, users with the Workflow Author role in a parent CID can only create workflows that trigger for that parent CID: Those users aren’t able to create workflows for that CID’s child CIDs.

   Tip: When creating a workflow that you will use with multiple CIDs, you can set up the workflow in a child CID to test and verify it first by triggering it and checking the execution log in the parent CID. Then, after verification, apply the workflow to more CIDs. For more info, see Edit a workflow’s CIDs in a Flight Control environment.

   When applying a workflow to child CIDs, you have these options:

   Option	Description
   All child CIDs	Applies the workflow to all current and future child CIDs. However, you can explicitly exclude some CIDs.
   Specific CIDs	Applies the workflow only to the CIDs you specify.
   Only current CID {CID_name}	Applies the workflow only to the current CID.

   If you define a workflow in a parent CID, the definition of the workflow, its execution log, and its audit log are only shown in the parent CID and not any of its child CIDs.

4. Select whether to create a workflow from scratch, by using a playbook, or by importing a workflow, and then click Next.

   • From scratch: Define all of the settings of the workflow yourself.

   • Playbooks: To help you create your workflow, several playbooks are available. They serve as templates that you modify to quickly set up workflows in your environment. Playbooks simplify and automate common use cases and demonstrate workflow possibilities. Each playbook includes its own setup steps. For more info, see Fusion SOAR Playbooks.

   • Import: If you have exported a workflow, you can import its definition file.

     For more info, see Export or import a workflow.

     If you import a workflow, skip the rest of these steps and follow the steps in Import a workflow instead.

5. If creating a workflow from scratch, find an event-based trigger or select a trigger type:

   • Event: The workflow is triggered by an event in the Falcon environment.

     To find an event-based trigger, use the search field or browse the lists of use cases. Either way, you can filter the triggers shown and adjust the sort.

     For info about event triggers, see Workflow triggers.

   • Scheduled workflow: The workflow is triggered regularly, based on a defined schedule, such as hourly, daily, weekly, or monthly. These options are available to specify the details of the workflow schedule:

     • How often: Schedule a workflow to run hourly, daily, weekly, or monthly.

     • Start time: Specify a time for the workflow to start. For example, if you specify a daily workflow, you can set it to start at 2 AM each day.

     • Time zone: Specify the time zone that should be used for running the scheduled workflow. The workflow settings, such as start time, adhere to this time zone, not the time zone of a Falcon console user or an asset like an affected host.

     • On these days: For weekly or monthly scheduled workflows, select one or more days of the week or month to run the workflow. For example, you can specify a monthly workflow to run on the 1st and 15th days of the month or you can specify a weekly workflow to run on Tuesday and Thursday of each week.

     • Add start or end date: Optionally, specify a date to start or end the schedule for the workflow runs. If specified, the workflow runs according to the specified schedule only during the selected timeframe.

     Skip if a previous execution is still in progress: Select if you want to skip an iteration of the scheduled workflow if the previous iteration is still in progress. For example, if you have an hourly scheduled workflow, you might not want to start a new iteration if the previous hour’s workflow is still in progress.

     Tip: You can also run this type of workflow immediately, as shown in Run a workflow on demand.
   • On demand: The workflow is triggered directly through the Falcon console, by another workflow, or by an API call, as shown in Run a workflow on demand. When setting up this trigger, you have these options:

     • If you prefer not to require any actions or fields when a user runs the workflow, go to the next step.

     • Specify the required items for the workflow to run by defining a JSON schema to specify the mandatory actions and fields.

       You have several ways you can define a JSON schema:

       • To find a sample to use, click Search schema samples. For example, if you want to get a detection ID or run a device query, there are samples that show you how.

       • To provide and convert JSON into JSON schema, click Generate schema and paste in the sample JSON.

       • To create the schema one property at a time, click Add property .

         Here’s an example JSON schema that requires a specific device as input:

         {
            "type": "object",
            "properties": {
               "deviceID": {
                  "type": "string",
                  "format": "aid"
               }
            }
         }

         You could use that input in a workflow to contain a device and create a Jira ticket to investigate the situation.

       For more info about JSON schema, see Manage action input, action output, and on-demand triggers.

   • Inbound webhook: The workflow generates a unique webhook URL for the given workflow and is then triggered by an external system that uses that URL. For more info, see Custom triggers based on inbound webhooks and Create and manage triggers based on inbound webhooks.

6. Click Next.

   • Your selected trigger appears on the workflow canvas.

   • To change the trigger selection, click the trigger element on the canvas and click Back to return to trigger selection.

     Tip: Throughout the process of building a workflow, the details panel shows helpful tips, warnings, and error messages.

   • Undo and Redo buttons are available.

7. In the Add next panel or on the workflow canvas, select Condition .

   
   
   

8. In the panel, make your selections to define the condition and click Next.

   For info about conditions, see Workflow conditions.

   Note: Conditions with a Matches or Does not match operator provide a blank field for you to enter your value. You must include an asterisk (*) at the start, end, or both of the value entered.

9. Refine the trigger further by adding more conditions. Click Next when all conditions have been added.

   In the example, an additional condition has been added to show how multiple conditions are grouped to visually indicate that all must be met for the workflow to be triggered.

   
   
   

10. In the Add next panel or on the workflow canvas, select Action to add the action to be performed when this condition is met.

11. Select and define an action.

    Note: Some workflow actions aren’t available based on their support for Flight Control environments. For example, Real Time Response (RTR) custom scripts are available in workflows, but only to 1 CID at a time. So even if you assign a custom script to the workflow for a parent CID and apply that workflow to child CIDs, the action for the workflow is only available in the workflow at the parent level.
    Note: Workflow actions that require specific subscriptions are only available to the child CIDs with those subscriptions.

    For an introduction to actions, see Workflow actions.

    For more info about how to set up some of the action options, see these topics:

    • Manage on-demand workflows that are used as actions
    • Create and manage actions based on event queries
    • Create an action in Fusion SOAR to perform an HTTP request
12. Click Test action to verify the action works as expected, without running the entire workflow. For more info about unit testing, see Test an action.
13. Click Next.

14. Review the workflow in the panel and canvas. With a trigger, conditions, and actions defined, this is a complete workflow. If the Issues panel opens, you have warnings or errors to resolve.

    Click Save and exit.

    • Enter a name and description for the workflow.
    • Optional. Set Status to On if you have no outstanding warnings or errors to resolve.
15. Optional. Define workflow output to save data for later use. For more info, see Save data using workflow output.

16. Click Save and exit.

Add sequential or parallel elements to your workflows by adding them to the canvas and defining them.

1. Hover over the trigger and click to expand the menu.

   
   
   

2. Select an option:

   Note: You can define an action based on an event query. For more info, see Event queries, or saved searches, as workflow actions.
   Note: Whenever you have parallel loops, make sure they're iterating through different data sources.

   • Sequential action: Add an action to the current workflow branch

   • Sequential loop: Add a loop to the current workflow branch

   • Parallel action: Create a branch with an action

   • Parallel condition: Create a branch with a condition

   • Parallel loop: Create a branch with a loop

   Tip: If you pick an option but then decide you want a different one, click Change.

3. Define and save your elements.

ELSE, IF conditions and ELSE actions let you create separate workflow branches for different conditions.

1. On the workflow canvas, hover over the condition and click to expand the menu.

   
   
   

2. Select an option:

   • Else If condition: Creates a condition branch that is checked if the condition you branch from is not met

     For info about conditions, see Workflow conditions.

   • Else action: Creates an action that is performed if the condition you branch from is not met

   • Else loop: Creates a loop that is performed if the condition you branch from is not met

   Tip: If you pick an option but then decide you want a different one, click Change.

3. In the details panel, define and save your elements.

Add loops to your workflows by adding them to the canvas and defining them in the details panel. Loops can be sequential or parallel. You can also nest loops. Add loops after triggers, conditions, and actions. The items available to loop through depend on the trigger, condition, or action.

For more info, see Looping in workflows.

1. Hover over the trigger, condition, or action where you want to add a loop and then, to expand the menu, click , , or .

2. Select an option:

   Note: Not all of these options appear all the time. They appear based on context.
   Note: Whenever you have parallel loops, iterate through different data sources.

   For info about the Continue workflow on loop iteration failure option, see Loop iteration failure.

   • Loop: Create a While loop or a For each loop to iterate through items

   • Parallel loop: Create a branch with a loop to run at the same time

   • Sequential loop: Add a loop to execute in a specific order in the current workflow branch

   Tip: If you pick an option but then decide you want a different one, click Change.

3. To nest a loop inside another loop, hover over the beginning of the loop where this new loop should be nested and click

4. Define the loops and finish defining the workflow.

   Note: The first condition or action that you set in a loop must be based on items the loop is iterating through. If not, you can get an error that prevents you from continuing to the next step. For example, with a trigger of Detection > EPP Detection followed by a loop that iterates through Host tags, the first condition or action in the loop should be defined using Host tags instance. However, if you set that first condition or action to be the Contain device action, you'll get an error because the Contain device action doesn’t involve the items being looped through.

When creating or modifying a workflow, you can copy a single node such as an action or condition and paste it in an appropriate location on the canvas. Copying a loop is similar. For more info, see Copy and paste a loop.

Copy and paste an action or condition:

1. Hover over the node and click Copy .
2. On the canvas, at the location where you want to paste the node, click Add , then click Paste .

   Paste is not available if pasting is not allowed in the selected location. For example, you can't paste an action node on a condition's Else If branch.

3. The new node displays and contains the same configuration information as the original node.

   By default, the name of an action node is incremented each time it is pasted, such as Send email - 2 and Send email - 3. Click each node and click Edit to give them more meaningful names when viewing the canvas.

4. If there are validation errors, an error indicator displays.
5. Click the node and update the information for the new context.
6. When all issues are resolved, click Save or Save draft.

Combine multiple parallel or conditional branches into a single branch in the workflow canvas.

• To join branches, click on a branch node and drag a path to the target branch. Click and hold to see available join locations in your workflow.

  Tip: Review your workflow after joining branches, as this may change workflow execution order.

• To delete a join node, click the node, click , and then click Delete to confirm.

1. Go to Fusion SOAR > Fusion SOAR > Workflows .

2. Click Open menu︙ for the workflow you want to duplicate.

   You can also click Open menu︙ for the workflow you want to duplicate on the Execution log tab or in the Execution details panel of the workflow.

3. Click Duplicate workflow.

   The duplicated workflow with “Copy of” prefixed to the Workflow name opens in Fusion SOAR.

4. Update and rename the duplicated workflow.

   For info about how to edit workflow elements in Fusion SOAR, see Edit a workflow element.

5. Click Save and exit to save the updated workflow.

   Note: Duplicated workflows are not saved until you click Save and exit.

To export a workflow definition:

1. Start an export from either of these locations:

   • The All workflows tab

     1. Go to Fusion SOAR > Fusion SOAR > Workflows .

     2. Click Open menu for the workflow you want to export.

     3. Click Export workflow.

   • The Workflow details page

     1. Go to Fusion SOAR > Fusion SOAR > Workflows .

     2. Click the name of the workflow you want to export.

     3. Click Open menu and then select Export workflow.

2. Enter a name and location for the workflow definition file.

3. Save the file.

   The workflow definition is saved to a YAML file.

4. If the workflow contains email addresses, some of the addresses are changed to [email protected]. Customize the addresses for use with a given CID when you import the workflow through the Falcon console. Otherwise, if you plan to use the API to import the workflow, edit the YAML file now to use addresses with email domains that are valid for the CID where you plan to import the workflow. For more info about the API, see Fusion SOAR Workflow APIs.

5. If the workflow is triggered based on a schedule that includes an end date, edit the YAML file to remove the line that contains end_date. Otherwise, importing the file can cause an error if the date is in the past.

To import a workflow definition:

1. Go to Fusion SOAR > Fusion SOAR > Workflows .

2. Click Create workflow.

3. For Flight Control environments, users with the Falcon Administrator role in the parent CID can choose which child CIDs the workflow applies to. Those workflows can trigger for any child CID, even if the users don’t have permissions in the child CIDs. However, users with the Workflow Author role in a parent CID can only create workflows that trigger for that parent CID: Those users aren’t able to create workflows for that CID’s child CIDs.

   Tip: When creating a workflow that you will use with multiple CIDs, you can set up the workflow in a child CID to test and verify it first by triggering it and checking the execution log in the parent CID. Then, after verification, apply the workflow to more CIDs. For more info, see Edit a workflow’s CIDs in a Flight Control environment.

   When applying a workflow to child CIDs, you have these options:

   Option	Description
   All child CIDs	Applies the workflow to all current and future child CIDs. However, you can explicitly exclude some CIDs.
   Specific CIDs	Applies the workflow only to the CIDs you specify.
   Only current CID {CID_name}	Applies the workflow only to the current CID.

   If you define a workflow in a parent CID, the definition of the workflow, its execution log, and its audit log are only shown in the parent CID and not any of its child CIDs.

4. Click Import workflow and then click Next.

5. Click Upload workflow file, and then browse to and select the workflow definition file to use.

6. Click Import workflow.

7. Enter a unique name for the new workflow.

8. Click Import workflow.

   If the import is successful, a page appears that allows you to customize the workflow.

   Note: This customization page appears even if no customization or configuration is needed.

9. Click Customize workflow.

   • If no changes are needed, click Continue.

   • If the workflow has actions that need configuration, you are stepped through each item that you must configure.

     When you complete the required steps, click Continue.

   • If the workflow includes a trigger based on an inbound webhook, enter the authentication information.

10. Click Save and exit.

Go to Fusion SOAR > Fusion SOAR > Workflows .

You can immediately run workflows that meet all of these requirements:

• The Trigger column contains Scheduled or On demand

• The Last modified by column contains an email address

• The Status column shows On

To run such a workflow immediately, click Open menu and select Execute workflow.

For on-demand workflows that require input, you are prompted to provide that input. For example, this prompt requests a deviceID.

Go to Fusion SOAR > Fusion SOAR > Workflows and click the Execution log tab.

You can immediately run workflows that meet all of these requirements:

• The Trigger column contains Scheduled or On demand

• The Last modified by column contains an email address

To run such a workflow immediately, click Open menu and select Execute workflow.

For on-demand workflows that require input, you are prompted to provide that input. For example, this prompt requests a deviceID.

Go to Fusion SOAR > Fusion SOAR > Workflows and click the Execution log tab.

You can immediately run workflows that meet all of these requirements:

• The Trigger column contains Scheduled or On demand

• The Last modified by column contains an email address

To run such a workflow immediately, click View execution details , click Open menu , and select Execute workflow.

For on-demand workflows that require input, you are prompted to provide that input. For example, this prompt requests a deviceID.

Go to Fusion SOAR > Fusion SOAR > Workflows .

You can immediately run workflows that meet all of these requirements:

• The Trigger column contains Scheduled or On demand

• The Last modified by column contains an email address

• The Status column shows On

To run such a workflow immediately, click the workflow name, click Open menu and select Execute now.

For on-demand workflows that require input, you are prompted to provide that input. For example, this prompt requests a deviceID.

When you create a workflow that includes an on-demand trigger, Fusion SOAR automatically creates an action based on that workflow. To start that workflow from another workflow, add the action based on the workflow in the other workflow.

For example, assume whenever you contain a device, you must also create a Jira ticket to follow up. You could create an on-demand workflow that does both the containment and the Jira ticket creation. Other workflows could then trigger the on-demand workflow rather than do the containment directly.

Call an on-demand workflow from a workflow:

1. Go to Fusion SOAR > Fusion SOAR > Workflows .

2. Verify that the on-demand workflow that the action is based on is enabled.

   For an action based on a workflow to be available, its workflow must be enabled.

3. Click Create workflow or click the name of workflow where you want to add the action.

   If you’re editing a workflow, click Edit.

4. In the workflow canvas, hover over the trigger, condition, or action where you want to add the action and then, to expand the menu, click , , or .

5. Add the action for the on-demand workflow.

   Note: The name of the action is the name of the on-demand workflow.

6. Define or edit the rest of the workflow as needed and save it.

If a workflow uses a Schedule trigger or an On demand trigger, in addition to running the workflow on demand from the Falcon console, you can use the /workflows/entities/execute API endpoint.

For more info about this API, see Fusion SOAR Workflow APIs.

Execute a Falcon Fusion SOAR on-demand workflow in the case workbench, in the On-demand workflows section of an applicable entity’s summary panel. For more info, see Case Investigation.

1. Go to Fusion SOAR > Fusion SOAR > Workflows .

2. Click Create workflow, select how to create the workflow, and continue to the workflow canvas.

3. In the Add trigger panel, click Inbound webhook.

4. Enter a name and optionally a description.

5. Select the HTTP method.

6. Select the authentication type.

   Anyone trying to start the workflow from an external system will have to provide any authentication info entered here to trigger the workflow.

   • Basic: Enter a username and password.

   • HMAC: The hash algorithm is automatically selected. Enter a secret, select the signature encoding, and enter the signature header name, which is the header in the request, such as X-Signature, that will contain the signature.

     The message digest is used in forming the signature. The request body is always included in this digest. You can also include Timestamp and Message ID in the digest.

     When you enable HMAC authentication, for each request from a tool outside of Fusion SOAR, you must use the same hash algorithm, secret, and encoding to compute the signature that you place in the specified header.

   • API key: Enter a key and select whether the key will be found in the requests' header or body.

7. Complete the fields for the chosen authentication type.

8. Optional. If you'd like to set a particular response body or response code, click Add advanced configuration and enter the desired info.

   By default, the response body is empty and the response code is 200.

9. Optional. To improve the security of the trigger, configure a range of IP addresses that are allowed to invoke the webhook. Click Add advanced configuration and then Allowed IPs. Enter each value as a CIDR notation IP address with a prefix length, such as 192.0.2.0/24 or 2001:db8::/32, as defined in RFC 4632 and RFC 4291.

   Note: Fusion SOAR normalizes these values to be in expected network ranges. For example, it changes 12.13.14.15/12 to 12.0.0.0/12.

10. Click Generate URL.

    Fusion SOAR creates the URL that you'll use in an external system to trigger the current workflow.

    The generated webhook endpoint URL is specific to the workflow where its trigger was created. You can't use the URL with other workflows.

11. Copy the URL to immediately add to the external system or to save for later.

12. Optional. Create a JSON schema for the request payload to enforce a format for the payload.

    You can listen for a live payload, enter a sample payload, or a combination of both.

    To view a history of webhook events and their output to use in creating the schema, click Execution history . You can filter the history for execution status and timeframe.

    Tip: To avoid enforcing a format and just pass through the entire payload, enter empty curly braces, {}, as the sample payload. When you use this technique, the workflow execution log shows the entire webhook payload. Also, if you use this technique, you can use data transformation functions to extract or transform the webhook payload. For more info, see Fusion SOAR Data Transformation Functions.

13. Click Next to add the trigger.

14. Define the rest of the workflow.

You can change the trigger's name, description, authentication configuration, advanced configuration, and payload schema.

For info about the authentication options, see Create a trigger based on an inbound webhook.

Note: If you want a different webhook URL with the same trigger definition, create a new workflow using the desired trigger definition and generate a new URL.

1. Go to Fusion SOAR > Fusion SOAR > Workflows .

2. Find and click the workflow.

3. Click Edit.

4. Click the trigger.

5. Make the desired changes.

6. Click Next.

If you have already created a trigger based on an inbound webhook and want to see the URL again to copy it:

1. Go to Fusion SOAR > Fusion SOAR > Workflows .

2. Find and click the workflow.

3. Click the trigger.

   A panel opens.

4. In the panel, locate the Webhook URL entry.

To inspect issues with a webhook, you have these options:

• Webhook event history

  Edit a workflow, click the trigger, and then click Execution history .

• Execution log

  Go to Fusion SOAR > Fusion SOAR > Workflows and click the Execution log tab.

• Events in LogScale

  Go to Investigate > Search > Advanced event search and run this query to get all of the webhook ingestion errors:

  #repo = fusion
  | "#event_simpleName" = FusionWorkflowEvent
  | "webhook_ingest_log_type" = IngestError

• Webhook Ingest Errors dashboard

  For more info, see Investigate webhook ingest errors.

Possible issues and their causes:

• Authentication: The request failed authentication.

  Common causes:

  • Missing or incorrect API key

  • Invalid Basic Auth credentials

  • Invalid HMAC signature because of the wrong secret, the encoding, or the message content

  • Missing required headers, such as X-Signature, X-Timestamp, or X-Message-ID

  Log subtype: Authentication

• ParsingPayload: The request body could not be parsed.

  Common causes:

  • Malformed JSON, possibly a syntax error

  • Incorrect Content-Type header; should be application/json

  • Empty or improperly encoded body

  Log subtype: ParsingPayload

• Internal: An unexpected error occurred during webhook processing.

  Common causes:

  • Server-side exception or infrastructure issue

  • Workflow misconfiguration

  • Fusion service failure

  Log subtype: Internal

• Schema Binding Failure: Data available in a condition or an action does not match the schema.

  Common causes:

  • Missing required fields, such as project.id

  • Incorrect field names or data types

  • Mismatched object or array structures

• Replay Protection Failure (HMAC): The request was rejected because of a replay detection.

  Common causes:

  • Expired or future-dated timestamp

  • Time sync issues between sender and Fusion

• Missing Required Headers: A required header for validation was not included.

  Common causes:

  • Missing signature header, X-Signature

  • Missing timestamp or message ID when HMAC replay protection is enabled

• Unsupported HTTP Method: The request used an invalid HTTP method.

  Common causes:

  • Sending GET instead of POST

  • Endpoint expecting JSON but receiving form data

• Rate Limiting: The system rejected the request because of the excessive frequency.

  Common causes:

  • Too many requests sent in a short period, which is rare in typical use

• Misconfigured Webhook Trigger: The webhook trigger is not properly set up.

  Common causes:

  • Missing or invalid webhook URL

  • Trigger was deleted or is inactive

  • Workflow is not enabled

To chain actions together and build better conditions, you must understand the input and output of the actions you’re using. By viewing a schema, you see which fields are required for its action, the properties for those fields, and their descriptions.

1. Go to Fusion SOAR > Fusion SOAR > Workflows .

2. If you're creating a workflow, click Create workflow, select how to create the workflow, continue to the workflow canvas, and add an action.

   If you’re editing a workflow, find and click an existing workflow that has actions you want to see schemas. Click Edit and select the action with the schema you want to see.

   Tip: If you create or edit a workflow with an On demand trigger, you can see sample schemas by clicking Search schema samples.

3. Click View schema.

   The schema viewer opens, showing a form-based version of the schema.

   To view the raw JSON, click View JSON Schema.

   Note: The form-based schema builder is not available when the JSON is more complex and can’t be represented in the form-based version.

   The form-based schema builder shows the fields and their types. To see a field’s properties, click the field. If a field is an array, click View JSON Schema to see its properties.

   This image shows the properties for the parentID field.

   

Each field in a schema can have numerous properties. Edit properties using the form-based schema builder or directly in the JSON. Use properties to provide context for a field, restrict inputs, and more.

While the form-based schema builder simplifies many aspects of editing a JSON schema, it does not support arrays of scalars. To define or edit an array of scalars, you must edit the JSON directly. However, you can use the schema builder with arrays of objects.

Here is an example of an array of sensor IDs.

{
    "type": "object",
    "items": {
      "type": "object",
      "properties": {
        "devices": {
          "description": "A list of sensor IDs",
          "type": "array",
          "title": "Sensor IDs",
          "items": {
            "format": "aid",
            "type": "string",
            "pattern": "^[A-Fa-f0-9]{32}$"
          }
        }
      },
      "required": [
        "devices"
      ]
    }
  }

Here's an example of JSON that complies with this JSON schema:

{
   "devices": ["0302188e5dc9490e861af9c40bc23c15", "94e8963899f74ffdb330065738faa35a"]
}

However, this example JSON does not comply with the schema. Neither ID is the required 32 characters, plus the second ID contains special characters.

{
   "devices": ["bc23c15", "%7!4(ffdb33006a35a)"]
}

To set a field to populate with valid options, use the x-cs-pivot property. This property specifies a set of data to look up as someone, for example, configures a field while using a workflow or adds an action based on an event query to a workflow.

To get various types of data, here are entity values you can use with x-cs-pivot:

If a user must enter any of the required fields, use anyOf in your input JSON schema.

In this example focusing on the anyOf portion, if the user enters any of the required fields, the entry is accepted:

"anyOf": [
    {
      "required": [
        "HostNames"
      ]
    },
    {
      "required": [
        "tags"
      ]
    },
    {
      "required": [
        "HostGroups"
      ]
    },
    {
      "required": [
        "aids"
      ]

In the context of the full input schema, the anyOf portion is at the end of the schema:

{
  "properties": {
    "HostGroups": {
      "items": {
        "properties": {
          "HostGroup": {
            "type": "string",
            "title": "Host group",
            "format": "hostGroupName",
            "x-cs-pivot": {
              "entity": "devices.groups.name"
            }
          }
        },
        "type": "object"
      },
      "type": "array"
    },
    "HostNames": {
      "items": {
        "properties": {
          "Hostname": {
            "type": "string",
            "title": "Host name",
            "format": "hostname",
            "x-cs-pivot": {
              "entity": "devices.hostname.raw"
            }
          }
        },
        "type": "object"
      },
      "type": "array"
    },
    "aids": {
      "items": {
        "properties": {
          "aid": {
            "pattern": "^[A-Fa-f0-9]{32}$",
            "type": "string",
            "title": "Inputted Agent Id",
            "format": "aid"
          }
        },
        "type": "object"
      },
      "type": "array",
      "title": "Agent Ids"
    },
    "tags": {
      "items": {
        "properties": {
          "tag": {
            "type": "string",
            "title": "Grouping tag",
            "x-cs-pivot": {
              "entity": "devices.tags"
            }
          }
        },
        "type": "object"
      },
      "type": "array"
    }
  },
  "type": "object",
  "anyOf": [
    {
      "required": [
        "HostNames"
      ]
    },
    {
      "required": [
        "tags"
      ]
    },
    {
      "required": [
        "HostGroups"
      ]
    },
    {
      "required": [
        "aids"
      ]
    }
  ]
}

1. Go to Fusion SOAR > Fusion SOAR > Workflows .

2. Find the workflow to edit and click Open menu for that workflow.

3. Select Edit workflow.

   If any other workflows use the action based on the on-demand workflow, a list of those workflows appears.

4. Choose one option:

   • If you’re not going to edit the trigger, click Proceed.

   • If you are going to edit the trigger, in the list of workflows, click duplicate.

     The workflow is duplicated and shown in the current browser tab. Edit the duplicate workflow.

5. Complete your workflow edits and save the changes.

If the action based on the on-demand workflow is used in any other workflows, you must remove that action from the other workflows before you can delete the on-demand workflow.

1. Go to Fusion SOAR > Fusion SOAR > Workflows .

2. Find the workflow to delete and click Open menu for that workflow.

3. Select Delete workflow.

   If any other workflows use the action based on the on-demand workflow, a list of those workflows appears.

   Remove the action from one of those workflows:

   1. Click a workflow name in the list.

      The workflow opens in a new tab.

   2. Click Edit.

   3. Hover over the action to delete and click Delete .

      A warning appears.

   4. Click Delete.

   5. Click Save and exit.

   6. Add a comment to describe the change to the workflow for its version history.

   7. Click Update workflow.

      The All workflows tab opens again. You can close this browser tab.

   8. Go back to the original browser tab and click Go back.

      The All workflows tab opens again.

   9. Continue to remove the action from other workflows by repeating steps 2 and 3.

      When the action is no longer in any workflow, finding the on-demand workflow and clicking Delete workflow deletes the on-demand workflow.

1. Go to Fusion SOAR > Fusion SOAR > Workflows .

2. Click Create workflow, select how to create the workflow, and continue to the workflow canvas--or click the workflow where you want to add the action.

   If you're editing a workflow, click Edit.

3. Hover over the trigger, condition, or action where you want to add an action and then, to expand the menu, click , , or .

4. Select Action .

5. In the Add action panel, click Create event query.

6. Select Workflow-specific query or CID-specific query.

   For info, see Event queries, or saved searches, as workflow actions.

7. Click Next.

   The query builder appears.

8. Configure the query.

   1. Set Data view to the data source to query. The available sources depend on your subscriptions and role. For more info, see Requirements. Here are the options:

      • All: All event data in Falcon, Forensics, IT Automation, and XDR

      • Falcon: Endpoint event data and sensor events

      • Forensics: Triage data collected by Falcon Forensics

      • IT Automation: Event data generated by Falcon for IT

      • Third Party: Event data generated by integrated third parties

   2. Enter a name for the query in Query name.

   3. Optional. Enter a description for the query to help you and others later understand the purpose of the query.

   4. Optional. To provide test data to run the query against, click Upload test data.

      If you’re creating an event query action for data that doesn’t yet exist, you can upload test data in a JSON file–up to 20,000 records–to verify the query and create the action.

      The file you upload must consist of data that uses one of these formats:

      • One pair of brackets around one or more pairs of braces:

        [
        { }, 
        { }, 
        { }
        ]

      • One or more pairs of braces, separated by new lines:

        { }
        { }
        { }

      Whenever you upload data, click Run to refresh query results.

   5. Enter your query and run it, modifying it and running it until you get the desired results.

      For info about the query language, see Get Started with CrowdStrike Query Language.

      Important: Schema generation removes certain special characters, such as @ and #, from the event query output. If you have characters removed, create a new field in the query using the assignment operator. For example: myTime := @timestamp. Then, reference the new field so that the schema uses the new field name.
      Tip: To format query results as a table before sending them in an email or other notification-based action, use the table() function. For more info, see table().

   6. Click Continue.

      A new window opens with these tabs: Query, Input schema, and Output schema.

      Fusion SOAR generates the schemas based on the query and its results when the Automatically generate schema option is selected.

      Important: Be sure that the output includes all the fields you need, especially fields you plan to use in conditions or as action input. Also, fields marked as required must be in the output. The action fails with a schema validation issue if any of the required fields are not in the output. Only mark a field as required if you can guarantee the field is always in the output. If the field is dynamically populated, consider leaving all fields as optional and using a condition to check that the field has a value before using the field, as suggested in a later step.

      For more info about these schemas, see Customize an event query action’s input and output.

   7. Optional. To adjust either of the schemas to better define the requirements you want for the query’s input or output, click Input schema or Output schema and then . When done, click Save changes.

      Note: For the input schema, you can only edit the metadata. You can’t edit the schema.

   8. Click Add to workflow.

      By default, actions based on CID-specific event queries go in the Other (Custom, Foundry, etc.) group. Later, if you want to add the action to another workflow, search for the action by name or browse for it in this group.

9. Optional. Adjust the time window for the query by entering values in the End time and Start time fields. By default, you select values from dropdown menus. To clear a selection, click Select an option. For more options, click and enter times using the syntax in Relative Time Syntax, excluding the Advanced Time Syntax.

10. Optional. Actions based on event queries place their search results in their output for use with, for example, the Send email action and Jira ticket creation. The results are always available in JSON. If you would also like the results in CSV, in the Add action panel, select Export to CSV. When you choose this option, you can select the exact fields to include in the result using the CSV header fields to export field.

    Tip: Large results might fail a workflow. Selecting the Only return results as files option might help avoid those failures. However, the Full search results and Event query results fields accessed by iterating over the results using a workflow loop are not accessible when using this option.

    For more info, see Add search results as an attachment.

11. Click Next.

12. Define or edit the rest of the workflow as needed, resolve any warnings or errors, and save it.

    Important: Create a condition to confirm the query found matches and that any required fields are populated. See Verify the event query action output is nonempty before acting on it.

1. Go to Fusion SOAR > Fusion SOAR > Workflows .

2. If you're creating a workflow, click Create workflow, select how to create the workflow, and continue to the workflow canvas.

   If you're editing a workflow, click the workflow you want to edit to include the action and then click Edit.

3. Hover over the trigger, condition, or action where you want to add an action and then, to expand the menu, click , , or .

4. Select Action .

5. In the Add action panel, find the action based on the query. You can search for it by name or browse for it in the Other (Custom, Foundry, etc.) group. In addition, all actions based on event queries include Event Query at the beginning. Because of that convention, you can search for Event Query to find all the actions based on event queries.

6. Select the action.

7. Click Next.

8. Create a condition to confirm the query found matches.

   Be sure that the output includes all the fields you need, especially fields you plan to use in conditions or as action input. See Verify the output fields of an event query action.

   Also, fields marked as required must be in the output. The action fails with a schema validation issue if any of the required fields are not in the output. Only mark a field as required if you can guarantee the field is always in the output. If the field is dynamically populated, consider leaving all fields as optional and using a condition to check that the field has a value before using the field. See Verify the event query action output is nonempty before acting on it.

9. If the Issues panel opens, resolve any warnings or errors you see.

10. Click Save and exit.

11. Add a comment to describe the change to the workflow for its version history.

12. Click Update workflow.

When you update an action based on a query, you update its query configuration to change its data source, name, the query itself, or its schemas. You can't change the type of the query, which is either workflow-specific or CID-specific.

If an action is used in multiple workflows, edits you make for one workflow might not be suitable for another. The steps below guide you through this scenario.

To edit an action based on a query:

1. Go to Fusion SOAR > Fusion SOAR > Workflows and click a workflow that uses the action.

2. In the workflow, click Edit.

3. Click the action to edit.

   The Action panel shows the action.

4. Click Manage event query.

   The event query manager opens.

   Note: By clicking Back instead of Manage event query, you can replace the action with another action.

5. Click Edit .

   Important: If other workflows use the action, a dialog provides the names of those workflows. If you click Proceed, you can still edit the query configuration. If your changes break any of the affected workflows, you are prompted after you click Continue in the next step to cancel, remove the dependencies, or save the changes in a duplicate.

6. Edit the query configuration.

   Change one or more of the configuration settings:

   • Set Data view to a different data source to query. The available sources depend on your subscriptions and role. For more info, see Requirements. Here are the options:

     • All: All event data in Falcon, Forensics, IT Automation, and XDR

     • Falcon: Endpoint event data and sensor events

     • Forensics: Triage data collected by Falcon Forensics

     • IT Automation: Event data generated by Falcon for IT

     • Third Party: Event data generated by integrated third parties

   • Change the name for the query in Query name.

   • Optional. Enter or change a description for the query to help you and others later understand the purpose of the query.

   • Optional. To provide test data to run the query against, click Upload test data.

     If you’re creating an event query action for data that doesn’t yet exist, you can upload test data in a JSON file–up to 20,000 records–to verify the query and create the action.

     The file you upload must consist of data that uses one of these formats:

     • One pair of brackets around one or more pairs of braces:

       [
       { }, 
       { }, 
       { }
       ]

     • One or more pairs of braces, separated by new lines:

       { }
       { }
       { }

     Whenever you upload data, click Run to refresh query results.

   • Change the query and run it, modifying it and running it until you get the desired results.

     Note: The input schema is automatically updated. However, if you want Fusion SOAR to update the output schema, select the Automatically (re)generate schema option. You must change the query itself or its time interval for schema regeneration to occur.

     For info about the query language, see Get Started with CrowdStrike Query Language.

     Important: Schema generation removes certain special characters, such as @ and #, from the event query output. If you have characters removed, create a new field in the query using the assignment operator. For example: myTime := @timestamp. Then, reference the new field so that the schema uses the new field name.
     Tip: To format query results as a table before sending them in an email or other notification-based action, use the table() function. For more info, see table().

   • Click Continue.

     A new window opens with these tabs: Query, Input schema, and Output schema.

     Fusion SOAR generates the schemas based on the query and its results.

     Important: Be sure that the output includes all the fields you need, especially fields you plan to use in conditions or as action input. Also, fields marked as required must be in the output. The action fails with a schema validation issue if any of the required fields are not in the output. Only mark a field as required if you can guarantee the field is always in the output. If the field is dynamically populated, consider leaving all fields as optional and using a condition to check that the field has a value before using the field, as suggested in a later step.

     For more info about these schemas, see Customize an event query action’s input and output.

   • Optional. To adjust either of the schemas to better define the requirements you want for the query’s input or output, click Input schema or Output schema and make your changes. When done, click Save changes.

     Note: For the input schema, you can only edit the metadata. You can’t edit the schema.

7. Optional. Adjust the time window for the query by entering values in the End time and Start time fields. By default, you select values from dropdown menus. To clear a selection, click Select an option. For more options, click and enter times using the syntax in Relative Time Syntax, excluding the Advanced Time Syntax.
8. Optional. Actions based on event queries place their search results in their output for use with, for example, the Send email action and Jira ticket creation. The results are always available in JSON. If you would also like the results in CSV, in the Action panel, select Export to CSV. When you choose this option, you can select the exact fields to include in the result using the CSV header fields to export field.

   Tip: Large results might fail a workflow. Selecting the Only return results as files option might help avoid those failures. However, the Full search results and Event query results fields accessed by iterating over the results using a workflow loop are not accessible when using this option.

   For more info, see Add search results as an attachment.

9. Click Next.

10. If you don't already have a condition to confirm the query found matches and that any required fields are populated, create one. See Verify the event query action output is nonempty before acting on it.
11. If the Issues panel opens, resolve any warnings or errors you see.

12. Click Save and exit.

13. Add a comment to describe the change to the workflow for its version history.

14. Click Update workflow.

    By default, actions based on CID-specific event queries go in the Other (Custom, Foundry, etc.) group. Later, if you want to add the action to another workflow, search for the action by name or browse for it in this group.

You can remove an action based on a CID-specific event query from a workflow–leaving the action available to other workflows.

If you prefer to delete an action so that it’s no longer available, see Delete an action based on a CID-specific event query.

1. Go to Fusion SOAR > Fusion SOAR > Workflows and click the workflow with the action to remove.

2. In the workflow, click Edit.

3. Hover over the action to delete and click Delete .

   A warning appears highlighting any nodes affected by the deletion.

4. Click Delete.

5. Click Save and exit.

6. Add a comment to describe the change to the workflow for its version history.

7. Click Update workflow.

   Tip: Remove any conditions used to confirm that the query found matches. These conditions check Event count.

With an action based on a workflow-specific query, deleting the action is equivalent to removing the action from the workflow. There is no option to remove the action from the workflow while preserving the action for use in other workflows.

1. Go to Fusion SOAR > Fusion SOAR > Workflows .

2. Click the workflow that uses the action you want to delete.

3. Click Edit.

4. Hover over the action to delete and click Delete .

   A warning appears.

5. Click Delete.

6. Click Save and exit.

7. Add a comment to describe the change to the workflow for its version history.

8. Click Update workflow.

You can delete an action based on a CID-specific event query so that it is no longer available to any workflow. If the action is used in multiple workflows, you must first remove the action from all workflows that use the action.

If you only want to remove an action from a workflow without deleting the action, see Remove an action based on a CID-specific event query from a workflow.

1. Go to Fusion SOAR > Fusion SOAR > Workflows .

2. Use the Actions filter to show only the workflows that use the action you want to delete.

3. For each workflow with the action, click Open and then select Edit workflow and remove the action from that workflow:

   1. Hover over the action to delete and click Delete .

      A warning appears.

   2. Click Delete.

   3. Click Save and exit.

   4. Add a comment to describe the change to the workflow for its version history.

   5. Click Update workflow.

   With the action no longer in any workflow, you can delete the action.

4. To delete the action:

   1. Go to Fusion SOAR > Fusion SOAR > Workflows .

   2. Click Create workflow.

      You only need this workflow temporarily. You will discard the workflow after you delete the action.

   3. Start to define a workflow so that you can add an action.

   4. In the Add next panel the workflow canvas, click Action .

   5. Find the action to delete and select it.

   6. Click Manage event query.

      The event query manager opens.

   7. Click Delete .

5. You can now discard this temporary workflow.

   Click All workflows and then Discard workflow.

   Tip: Remove any conditions used to confirm that the query found matches. These conditions check Event count.

With some plugins, such as Jira and ServiceNow, you can add attachments to the tickets.

Event queries place their search results in their output.

If you’re using either of these plugins, you can attach the results to your tickets.

For actions created before October 1, 2024, the results are in the File info field of their output.

For actions created after October 1, 2024, the results are in the new JSON file field of their output. For these actions, you can also get the results in the CSV format, which is then available in the new CSV file field in the action's output. To get the CSV format, after you add an action to a workflow, select the Export to CSV option in the Action panel. When you select this option, the CSV header fields to export field opens. You can use this field to select the exact CSV header fields you want in the CSV file. If you don't select any fields in CSV header fields to export, the CSV file contains all of the header fields.

If an action based on an event query was created after October 1, 2024, the Export to CSV option is also available when editing that action.

For info about the roles needed to create and overwrite lookup files, see Requirements.

These are the related actions:

• Get lookup file metadata

  Use this action to collect info to check whether a file exists before you use the create or overwrite actions.

  Conditions that use this metadata can use built-in parameters or expressions that you define using data transformation functions. For more info about these functions, see Fusion SOAR Data Transformation Functions.

• Create lookup file

• Overwrite lookup file

Fusion SOAR only shows lookup files created or overwritten in Fusion SOAR. However, Next-Gen SIEM shows its lookup files and any lookup files you create in Fusion SOAR.

When you create or overwrite a lookup file, you configure these items:

• Repository or view

  Select the repository or view that corresponds to the repository or view that the related query action is using.

• Name

  The name must end with .csv or .json.

  Also, the name must be unique within the repository or view you selected.

  To ensure uniqueness, you can insert a variable, such as Workflow_execution_ID, in the name.

  The name must be at least 5 characters but not more than 100 characters.

• Content type

  Define the lookup file by selecting a file created by a previous action, by specifying a variable, or by entering plain text inline.

  The accepted formats are CSV and JSON.

  The maximum size file that you can upload is 10 MB.

  The maximum size for the value of a variable is 10 MB.

  The maximum amount of text that you can enter inline is about 1 MB.

  The JSON formats accepted are the same as the JSON formats accepted by Falcon LogScale. Here are examples of those formats:

  • Object-based example

    {
      "1": { "name": "chr" },
      "2": { "name": "krab" },
      "4": { "name": "pmm" },
      "7": { "name": "mgr" }
    }

  • Array-based example

    [
      { "userid": "1", "name": "chr" },
      { "userid": "2", "name": "krab" },
      { "userid": "4", "name": "pmm" },
      { "userid": "7", "name": "mgr" }
    ]

Example

Assume we have log entries that contain status codes for a web server. These codes are in the field named status. To provide a name field to match names to the status codes, we could upload a lookup file named status_codes.csv with content that corresponds to this table:

To use that lookup file in a query, the query would then include a like line this one:

groupby([status])
| match(file="status_codes.csv", column=code, field=status, include=name)

When the query is run, the results might look something like this:

Make sure your event query action provides the output you expect. Verifying the output is particularly important when you plan to use it in a condition or loop or as input to another action.

You can check the output at various times:

• When you're creating an action based on an event query, after you click Continue, click Output schema.

• When you're editing an action based on an event query, click Output schema.

• Whenever you're curious about an action's output:

  1. Go to Fusion SOAR > Fusion SOAR > Workflows and click a workflow that uses the action.

  2. In the workflow, click Edit.

  3. Click the action to show the Action panel.

  4. Click View schema and then Output schema.

For more info about JSON schema, see Manage action input, action output, and on-demand triggers.

Every event query action includes an Event count field. This field indicates how many events the query found.

Before acting on the output of an event query action, verify the query found at least one event by setting a condition on the Event count field.

In the condition, use these settings:

Parameter: Event count

Operator: is greater than or equal to

Value: 1

The following image shows these settings.

To build conditions or actions based on the results of an event query, you must add a loop to iterate through the search results. For info about looping, see Looping in workflows.

For info about how to find fields to loop over in the search results, see Verify the output fields of an event query action.

In the example below, we pass each instance of the AID returned in the event query results to the Get connected USB drives action’s Device ID field.

Fusion SOAR generates schemas for the action’s input and output based on the query and its results. You can modify these schemas to better suit your needs. Use the input schema to define requirements for your action’s input and to help users of the action be successful when using the action. For example, a schema can validate input or help the user understand the variables to pass when using the action. Similarly, the output schema helps the user of the action understand what output to expect from the action.

• Example: Add a description, a default value, and validation to fields in the input schema
• Example: Trim an action’s output

The Cloud HTTP Request and On-Premises HTTP Request actions use these egress IP addresses.

Fusion SOAR can write data, such as output from an RTR script or an HTTP-based action, by using the Write to log repo action. The Write to log repo action saves output from either an On demand trigger or an action. You can then query the data through Investigate > Search > Advanced event search or use the data in other workflow actions.

For example, you could use this feature to write the output of an RTR script to a repository to access and search later.

To query the data interactively, go to Investigate > Search > Advanced event search and set the repo to Fusion by using this text as the first line in your query:

#repo = fusion

Then define and run your query. For more info, see Advanced Event Search.

Alternatively, later actions, either in the same workflow or other workflows, can use an event query with the Data view set to All to process that data. If you're querying the data within the same workflow and the data is not yet available, add a Sleep action. For more info, see Event queries, or saved searches, as workflow actions.

In Flight Control environments, workflows in a parent CID can write data into the parent CID’s own data view but not to any of the data views in the child CIDs. However, workflows in a parent CID can query data in the data views in the child CIDs.

1. Go to Fusion SOAR > Fusion SOAR > Workflows .

2. Create or edit a workflow.

3. Set up the data to save. You have these options:

   • The workflow uses an On demand trigger followed immediately by a Write to log repo action.

     You define the trigger's JSON schema to require input:

     1. In the schema builder, add a property, such as raw_json, of type string.

     2. Click the property to show its basic properties.

     3. Set Format to Raw JSON string.

     When someone runs the workflow, they are prompted for the data. That person uses one of these formats:

     • For one record:

       {"foo":"bar"}

     • For multiple records:

       [{"a":"b"},{"c":"d"}]

     Then the Write to log repo action saves the data.

     

   • The workflow uses any kind of trigger and includes a Write to log repo action.

     You define the action's input JSON schema using one or more of these fields. The combination of the data from all 3 fields is saved.

     • Data to include

       Click in this field and select one or more items, one at a time.

       To simplify querying in the repo, select Remove action prefix.

     • Raw JSON data

       Select an option. These options are only available if the trigger or previous actions have schemas that define a property of type string with Format set to Raw JSON string.

     • Custom JSON data.

       Enter your JSON directly in this field.

       

4. Define or edit the rest of the workflow as needed, resolve any warnings or errors, and save it.

You can configure workflows to save output for you to view in the Falcon console or to act on programmatically.

If you define workflow output for an on-demand workflow, any workflow that runs the on-demand workflow can then use the output of that on-demand workflow.

When you create or edit a workflow, click Settings, followed by Select output data, and then select the output to include in the workflow executions.

This output is then available in the Execution log in the workflow's execution details.

To access that output, you have these options:

• Go to Fusion SOAR > Fusion SOAR > Workflows , click the Execution log tab, click the workflow, go through the execution details–where you can view the output or download it manually.

• Download the execution details and its workflow output using APIs discussed in Fusion SOAR Workflow APIs.

1. In the Falcon console, go to Fusion SOAR > Fusion SOAR > Workflows .

2. To edit an existing workflow, click Open menu︙ , then select Edit Workflow. To create a new workflow, click Create workflow. For more info, see Create a workflow.

3. In the Add next panel or on the workflow canvas, click Customize playbook and select Condition.

4. In the Condition panel, turn on Advanced mode. For more info, see Conditions in Advanced mode using data transformation functions.

5. In the Workflow data panel, scroll to Workflow > Execution.

6. Drag Workflow execution errors into the expression editor.

7. Create a CEL expression to check for errors based on your use case. For more info about CEL expressions, see Fusion SOAR Data Transformation Functions. Examples of expressions you can create:

   • Check if any errors exist

     data['Workflow.Execution.Errors'].size() > 0

   • Check for specific error types

     data['Workflow.Execution.Errors'].exists(e, e.Name == 'Timeout')

   • Check for unhandled errors

     data['Workflow.Execution.Errors'].filter(e, e.Handled == "")

8. Optional. Input custom JSON sample data to test the expression.

9. Click Next.

Important considerations:

• When building error handling into your workflows, consider using the Test feature to validate your error handling paths before enabling the workflow. For more info, see Test and debug your workflow.

• Review the Execution data to ensure errors are being handled as expected. For more info, see View the execution log.

• Errors stop subsequent actions from executing by default. Actions won’t run if there are unhandled errors in the workflow. To ensure your action executes, handle any errors by using the Continue on failure setting or Resume after Error action. For more info, see Resume workflow execution after an error occurs.

Follow these steps to configure your workflow to resume execution after an error has occurred.

1. In the workflow canvas, create an Action.

2. To enable this feature, on the Action Execution settings tab, select the Continue on failure checkbox.

3. Click Next.

4. Optional. Add sequential actions or conditions to your workflow.

5. Save and publish your changes to the workflow.

For complex workflows with multiple parallel branches, you can use the Resume after Error action instead. This action shows where error handling occurs, making branch merging clearer in the workflow canvas. It provides the same functionality as the Continue on failure option.

Build complex workflows by adding sequential actions to an existing Create Jira issue action. For example, you can attach a file associated with an endpoint detection to a Jira ticket to give additional context to an issue.

Requires one or more of these subscriptions:

• Next-Gen SIEM, or Falcon Complete powered by Next-Gen SIEM
• Falcon Foundry

Default roles:

• App Developer plus Workflow Author

• Falcon Administrator

1. On the SOAR Dashboard page ( Next-Gen SIEM > Fusion SOAR > Dashboard ), on the Create an integration for custom Fusion actions in Foundry banner, click Visit page.

   Tip: You can also go to Foundry > Foundry > Templates .

   The Foundry Templates page opens.

2. Click Deploy for your selected template.

   The message Deployment in progress appears.

   When the app has been deployed, the App overview page opens.

   Note: To edit, test, or delete operations, click Edit app.
3. Release the app.
   1. Click Release.
   2. In the Commit release dialog, for Change type, select Major.
   3. Add a description of the app in the Release notes field for this initial release, and click Release.

      The message Releasing deployment appears, followed by the message Deployment released successfully.

4. Install the app.
   1. Click View in app catalog.

      Your app's catalog details page opens, showing the list of releases.

   2. Click Install now.
   3. Acknowledge the app permissions information by clicking Accept and continue.
   4. If required, enter configuration information.
   5. Click Install app.

      When your app has been installed, a notification appears. API operations in the app are now available as third-party integration actions.

5. Add a third-party integration action to a workflow.
   1. Click Fusion SOAR in the installation message.
   2. On the SOAR Dashboard page ( Next-Gen SIEM > Fusion SOAR > Dashboard ), create a new workflow or edit an existing workflow. For info, see Manage workflows.
   3. Add a third-party integration action to the workflow. To locate the action, search using any of these names:
      • The app name
      • The name of the API integration configured in the Foundry app
      • The name of the API operation configured in the Foundry app

   4. Create a condition to confirm the API operations output.

      Be sure the output includes all the fields you need, especially fields you plan to use in conditions or as input to other actions.

      Also, fields marked as required must be in the output. The action fails with a schema validation issue if any of the required fields are not in the output. In Foundry, only mark a field as required if you can guarantee the field is always in the output. If the field is dynamically populated, consider leaving all fields as optional and then using a condition in Fusion SOAR to check that the field has a value before using the field.

For more info about adding an action to a workflow, see Workflow actions. For more info about Foundry apps, see Foundry.

To edit a third-party integration action, you must edit its source Foundry app. You can add, edit, or remove API operations. You can also add other app capabilities.

1. Go to Foundry > Foundry > App manager .
2. Search for the app by its name or description.
3. When you locate the app, from its Open menu , select Edit app.
4. Click the arrow on the Integrations panel.
5. In the Operations list, find the operation used by your workflow action, and from its Open menu , select Edit operation.
6. Modify the operation as required. For info about the fields, see Create an API integration using the UI.
   Tip: If the action is failing with a schema validation issue because required fields that are dynamically populated are not always in the output, consider leaving all fields as optional and then using a condition in Fusion SOAR to check that the field has a value before using the field.
7. Optional. Test your changes to the operation.
   1. Click Test in the side menu.
   2. Click Create to create a temporary configuration, enter required values, and click Create Configuration.
   3. Enter values for any required parameters, and click Test operation.

   A status of Operation succeeded (200) indicates a successful test.

8. Optional. Add other capabilities to the app. For info, see App Capabilities.
9. Click Done when finished.
10. Deploy the app to save your changes. For more info, see Deploy an App.
11. Release the app. For more info, see Release an App.
12. If the app was previously installed, and you marked the release as Major, update it in the app catalog. For more info, see Update an app version.