Using Integrations¶

Integrations are where you connect NodeZero to the other tools your team runs, such as your SIEM (Security Information and Event Management), your vulnerability management platform, or your ticketing system, and decide what NodeZero sends to each one.

This page covers the Integrations Settings page: how it is structured, what every control and state does, and what to do when something goes wrong. Credentials and setup steps for each integrated service on a corresponding page per vendor.

Contents¶

• How Integrations Are Structured
• Getting to the Integrations Page
• The Three Tabs
• Connected Integrations
• Adding an Integration
• Workflows
• Activity Log
• Managing Instances Over Time
• Multi-Instance Patterns
• Troubleshooting
• Frequently Asked Questions
• Glossary

How Integrations Are Structured¶

An integration is assembled from four parts, each configured on top of the one before it.

Connecting a Destination Does Not Send Anything to It¶

Connecting an instance proves that NodeZero can reach your system and that the credential works. No data moves until a workflow names that instance as a destination and that workflow is Active. The wizard says so on its final step:

Develop - US won't receive anything until a workflow names it as a destination.

Credentials and routing are separate steps because they are usually handled by different people. A platform engineer can connect a tenant without deciding what flows through it.

One Dataset, One Destination, per Workflow¶

A workflow carries exactly one dataset to exactly one instance. One dataset to two destinations is two workflows. Two datasets to one destination is also two workflows. Duplicate copies an existing workflow so you do not re-enter its details.

Getting to the Page¶

1. Select your account name in the top-right of the NodeZero Portal.
2. Go to Settings.
3. Select the Integrations upper tab.

Who Can See and Change It¶

Integrations are configured at the account level, not per user. What you set up here applies to the account named in the top-right account switcher. Confirm you are in the right account before you begin, especially if you manage client accounts.

Everyone can see this page. However, only Org Admins can change anything on it.

Your own role is shown under Settings > My Settings > User > Role, and every user's role is listed in the Settings > Users > Role column. H3 Admin and H3 Org Admin also appear in that column. These are Horizon3 support roles, not roles you assign.

Changes to integrations are recorded in Settings > Audit Log.

Not on This Page: Tripwire Webhooks¶

Tripwire alerts can also be sent to Splunk Cloud and Microsoft Sentinel, but those are configured as webhooks under Settings > Tripwires Webhooks rather than as connectors here. Neither appears in the connector picker.

The Three Tabs¶

The Integrations page has three tabs:

Connection problems live on the first tab, routing problems on the second, delivery problems on the third.

Connected Integrations¶

Connect vendor instances and monitor their health. Configure what each instance receives on the Workflows tab.

The page lists every connector you have at least one instance for, as a card. Each card carries the vendor logo, the connector name in Vendor • Product form, a one-line description of what that connector does, and a count of instances on the right.

Connectors and instances

The Instance Table¶

Each connector card contains a table of that connector's instances:

Instance Status¶

Instance rows use one of these statuses:

Action Needed Tells You Why in the Row¶

When an instance goes to Action needed, the reason appears directly beneath the status in the Status column:

🟡 Action needed

HEC rejected the token. Check the token is current and enabled for this connector.

The message names the failing element, usually the credential, the endpoint, or a permission. Read it before opening any menus.

Status reflects the connection; dispatch outcomes are tracked separately. An instance can show Connected while its Last Dispatch failed, which means the credential works but that particular send did not land. An instance at Action needed can still show a healthy Last Dispatch from before the credential changed.

Last Dispatch¶

Last Dispatch shows the outcome beneath the timestamp. A recent Success confirms the whole path is working: NodeZero built the dispatch and the destination accepted it. A – means nothing has ever been sent to this instance, which is expected while it has no active workflow.

Card Controls¶

• Add Instance – adds another instance of this same connector. Goes straight to the credentials step; you don't re-pick the connector.
• Take Action – bulk actions for the instances you have selected with the row check boxes.
• Toggle Columns (the columns icon) – show or hide columns in this table.
• Search instances – filters instances by label across every connector card.
• Add Integration – the full wizard, starting from connector choice. See the next section.

Row Actions¶

The Actions (⋮) menu at the end of each instance row holds, in order:

View Details · Add Workflow · Add Another Instance · Verify Now · Edit Instance · Deactivate · Delete Instance

See Managing Instances Over Time.

Bulk Actions¶

Tick the check box on one or more instance rows to enable Take Action, which offers Verify Now, Deactivate, Reactivate, and Clear Selection. Use it to verify a whole connector's instances at once, or to pause several at a time. Take Action is disabled until at least one row is selected.

Adding an Integration¶

Select Add Integration. A three-step wizard opens. The Summary panel on the right fills in as you go, so you can check the label and endpoint you have entered before submitting the credential.

Step 1 – Connector¶

Choose a connector. Your choice decides which data sets you can route, and how often they update.

Each card shows the vendor, the product, a one-line description, and chips listing the datasets that this connector accepts.

Connectors currently in the picker:

Select a card, then Next.

Choosing a connector

Step 2 – Authenticate¶

Instance details. Credentials are stored per instance and never shared. The fields below are what this connector requires.

The connector defines the fields on this step, so each one asks only for what it requires. One field is common to all of them:

• Instance label (required) – your name for this instance. It appears in workflow names, in the destination picker and in the Activity Log, so make it unambiguous to someone who did not set it up. The placeholder shows the pattern: Manufacturing BU – Production.

The rest are whatever that connector needs to reach your system and authenticate to it. Expect an endpoint and at least one secret, sometimes with a username or a project identifier alongside. Required fields are marked; secrets are masked as you type.

Adding instance details

Credentials are stored per instance and are never shared between instances. Two instances pointing at the same vendor hold two separate secrets. Secret fields are masked, with an eye icon to reveal what you typed before you submit.

Select Verify Authentication. NodeZero runs the save-time checks the connector defines, usually an endpoint-format check and a credential check. Nothing is sent to the destination at this stage.

Step 3 – Verify¶

Authentication passed on the previous step. This step checks that the credential carries the permissions and access the connector needs. How much can be confirmed depends on what the vendor exposes: some connectors can check access to named objects and record counts, others confirm the transport by sending a single synthetic test event.

On success:

✓ Connected and verified.

<Instance label> won't receive anything until a workflow names it as a destination.

You also get two toasts: Instance connected and All checks passed – this instance is healthy.

Success state: a connected and verified instance

Then choose:

• New Workflow – create the routing rule now, with this instance preselected as the destination. This is the only remaining step before data flows.
• Add Workflow Later – finish here. The instance appears on Connected Integrations with No workflows in its Workflows column.

Workflows¶

Route one data set to one destination. Duplicate a workflow to reach more destinations.

Workflows are grouped under the same connector cards as instances. Each row is one routing rule.

Workflows grouped by connector

Creating a Workflow¶

Select New Workflow (top right of the tab), or Add a workflow from an instance row, or New Workflow at the end of the Add Integration wizard.

Destination (required) Every instance across every connector, in one list, shown as <Connector> – <Instance label>. The destination determines which datasets you can send, so the Dataset list below repopulates whenever you change it.

Dataset (required) Only the datasets the selected connector accepts appear here.

Sync The connector determines how the workflow is triggered, and the panel states which mode applies:

CrowdStrike NG-SIEM supports Automatic dispatch only. Dispatches on its own, as new data arrives.

You do not choose between these. Each integration presents the trigger mechanism available to it, and the Sync column on the Workflows tab records which one a workflow uses. Where a connector dispatches on a manual trigger, the control sits on the page the data comes from. The Integrations page records that a workflow is manually triggered; it is not where you fire it.

Activate this workflow (check box, on by default)

Leave unchecked to save it without activating. Nothing dispatches until you turn it on.

Leave it checked for normal setup. Uncheck it to stage a rule for review before it starts sending, such as when you are pre-building routing for a tenant that is not live yet.

What gets dispatched to \<vendor>? An expandable Read More panel describing what the chosen dataset contains and when it is sent. This is the definitive description of what leaves NodeZero, so it is worth passing to whoever owns the destination system.

Select Save Workflow. You'll see Workflow saved and activated, and the row appears under its connector card.

New Workflow modal – creating a workflow

Workflow Row Actions¶

The Actions (⋮) menu on a workflow row holds:

Edit Workflow · Duplicate · View Dispatch Info · Delete

Activation is handled in bulk. Select one or more workflow rows to enable Take Action, which offers Activate, Deactivate, and Clear Selection.

Editing a Workflow¶

Select the workflow name, or select Edit Workflow from its ⋮ menu. The same panel opens as Edit Workflow. Destination and activation are editable; Dataset is locked, with the reason shown inline.

Editing a workflow, with the dataset locked

Duplicating a Workflow¶

Duplicate from the ⋮ menu copies the rule so you can point it at a second destination. Duplicating is how you send one dataset to several systems.

NodeZero warns you if a duplicate would be redundant:

Identical workflow already active. Both would dispatch the same data.

Deactivating and Reactivating Workflows¶

Select the workflow rows you want and use Take Action > Deactivate. This stops them dispatching without deleting anything:

1 workflow deactivated – history preserved

The workflow keeps its configuration and its dispatch history. Take Action > Activate turns it back on. Use this for a maintenance window on the destination system, or to stop traffic during an investigation.

Deactivating the instance pauses every workflow that targets it in one step. Use that when the whole destination is going offline.

Workflows Pointing at Deleted Instances¶

Deleting an instance deletes its workflows too, along with their dispatch history. See Deactivating and Deleting. This is the main reason to deactivate rather than delete.

You might also see a banner above the list:

12 workflows target a deleted instance and are not shown below.

These are workflows left behind by instances removed before deletion cascaded to them. Their destination no longer exists, so they cannot dispatch and there is nothing to fix. The count does not grow when you delete an instance today.

Activity Log¶

Every dispatch across all vendors and instances.

A chronological table of every send NodeZero has made, newest first.

Filter and search with:

• Search dispatches – free-text search across the log.
• Status column dropdown – narrow to Success, Failure, Partial, In progress, or Skipped.
• Workflow column dropdown – narrow to one workflow.
• Toggle Columns – show or hide columns.

Filters are held in the page URL, so a filtered view can be bookmarked or pasted to a colleague.

Dispatch Statuses¶

Each Activity Log row uses one of these outcomes:

Activity Log showing dispatches, newest first

The Dispatch Detail Page¶

View in the Details column opens a page for that one dispatch, at /settings/integrations/activity/<dispatch-id>. Each dispatch has its own URL, so you can paste it into a ticket and the next person lands on that run. Back to Activity Log returns you to the list.

The page carries a Summary (Status, Connector, Dataset, Records, Workflow, Sync, and Dispatched), a Delivery section naming the destination instance and its endpoint, and the Dispatch Log described below.

Dispatch Detail modal for a single dispatch

The Dispatch Log¶

The Dispatch Log records what happened inside a single dispatch. A count of entries sits above the table:

A successful dispatch has little or nothing here. A failed one carries the reason it failed.

Work a failure in this order:

1. Read Status and the Delivery destination on the dispatch page.
2. Read the Dispatch Log entries for the specific error.
3. If the cause was transient, or destination-side and since fixed, Retry from the Activity Log row. Records already delivered are not resent.

Dispatch Log entry for a failed dispatch

Retrying¶

Retry sits in the Actions (⋮) menu at the end of an Activity Log row, and appears only on rows that need it. A successful dispatch has no Actions menu, so an absent menu means there is nothing to retry.

If a workflow has never dispatched, you'll be told This workflow has no previous dispatch to retry.

Empty State¶

No dispatches yet. Activity appears here once a workflow runs.

Three things cause this after a completed setup: the workflow is Inactive, no qualifying data has been produced yet (an Automatic workflow waits for a pentest to complete or a tripwire to fire), or the dataset has no records in scope.

Managing Instances Over Time¶

From an instance's ⋮ menu on Connected Integrations:

Rotating a Credential¶

Replace a secret through Edit Instance; there is no separate rotate action. The secret field behaves differently from the others:

Leave blank to keep the stored credential

The stored secret is never displayed back to you. Leave the field empty and your existing credential is preserved while you change the label or endpoint; type a new value and it replaces the old one on save.

Editing is the right response to an expired or revoked token. It preserves the instance, its label and every workflow pointing at it. Deleting and recreating does not.

Saving an edit re-verifies the instance, so there is no need to run Verify Now afterwards. A change that breaks the connection moves the instance to Action needed and prints the reason under the status, such as HEC rejected the token. Check the token is current and enabled for this connector.

A save runs the authentication check. Run Verify Now to re-run the full set of health checks: before a large scheduled pentest, or to confirm a fix made on the vendor's side.

Verifying on Demand¶

Verify Now re-runs the connector's checks. You'll see Verifying <instance>… while it runs, then either:

✓ 1 instance verified – all checks passed

or

1 instance could not be verified – open Details to see which check failed

A failed verification also leaves the instance at Action needed, with the reason printed in its row.

Deactivating and Deleting¶

Deactivate switches the instance off and pauses the workflows that name it as a destination:

1 instance deactivated – workflows that name it as a destination are paused

Nothing is lost, and Reactivate brings it back. Use it for a maintenance window on the destination system or an ingest-budget squeeze.

Delete Instance is permanent, and removes more than the instance:

Deleting removes the instance, its 2 workflows, and their dispatch history.

This can't be undone.

No audit trail of what was sent to a deleted instance survives. Deactivate instead if you might want that history.

Multi-Instance Patterns¶

Several instances of the same connector is a supported setup. Common reasons:

Regions and data residency. A separate tenant per region, each with its own endpoint and credential. Label them with the region: Falcon – US-2, Falcon – EU-1.

Environments. A dev or staging tenant alongside production, so you can prove a change before it reaches the SOC (Security Operations Center) queue. Put the environment in the label rather than leaving it implied: Develop - US, Production - US.

Business units or subsidiaries. Separate tenants for separately-run parts of the organization. Label with the Business Unit: Manufacturing BU – Production.

Migration. Run the old and new tenant in parallel by duplicating each workflow onto the new instance, confirm both are landing in the Activity Log, then deactivate the old workflows and delete the old instance.

Naming Instances¶

In the destination picker, the label is all that distinguishes two instances of the same connector. Sending proof of exploitation to the wrong tenant is a security incident, so make labels hard to confuse. Recommended pattern:

<Scope> – <Environment>          Manufacturing BU – Production
<Vendor region> – <Environment>  Falcon US-2 – Production

Avoid placeholder names, and avoid two labels that differ by a single character.

Troubleshooting¶

Work through these in order.

Frequently Asked Questions¶

Does connecting an integration start sending data? No. Connecting proves the credential works. Nothing is sent until an Active workflow names that instance as a destination.

Where are my credentials stored, and are they shared? Credentials are stored per instance and are never shared between instances. A stored secret is never displayed back to you. To replace one, use Edit Instance and type the new value into the secret field. Leaving it blank keeps the credential you already have.

Can I send the same dataset to two systems? Yes. Create one workflow per destination: Duplicate the first and change the destination on the copy. Each destination gets its own workflow row, status, and dispatch history.

Can one workflow send two datasets? No. One workflow carries exactly one dataset. Create a second workflow.

Can I filter what gets sent, such as criticals only or certain hosts only? Not currently. Each dataset has a defined scope, and the routing rule carries no user-configurable filters or transforms. The What gets dispatched? panel on the workflow describes what each dataset contains.

How do I test without touching production? Connect your vendor's non-production tenant as its own instance and route there first. Once that looks right, add the production instance and duplicate the workflows onto it.

Will a retry duplicate records in the destination? No. Dispatches carry an idempotency key, so records already delivered are never sent twice.

How do I pause an integration temporarily? Deactivate the instance, which pauses every workflow that names it in one step. To stop only part of the flow, deactivate individual workflows instead. Both preserve history. Deletion is permanent and is not a way to pause.

What happens to my dispatch history if I delete an instance? It is deleted with it. The confirmation states this: Deleting removes the instance, its N workflows, and their dispatch history. This can't be undone. Deactivate instead if you might want that audit trail.

Is any of this per-user? No. Integrations are account-level configuration. Everyone with access to the account's settings sees the same instances and workflows. Changes are recorded in the Audit Log.

All the times are in UTC. Can I change that? No. Dispatch timestamps are shown in UTC throughout, so they line up with the timestamps in the destination systems.

Glossary¶

Connector – a supported destination type, built by Horizon3. It defines which credential fields are required, which datasets can be routed, and how dispatch is triggered.

Instance – one configured tenant of a connector, with its own label, endpoint, and credential.

Dataset – a named slice of NodeZero output. Which ones are available depends on the connector.

Workflow – a routing rule: one dataset > one instance. Active or Inactive.

Dispatch – a single send from NodeZero to a destination, triggered by a workflow. Recorded in the Activity Log.

Sync – how a workflow is triggered: Automatic (on its own, as new data arrives) or Manual trigger.

Idempotency key – the identifier attached to each dispatch that lets a retry skip records the destination already has.