24. Integrations

The page where you wire Daalu into your world — guided wizards, notification channels, and ingest sources that light up everything else.

At a glance

Three things share the name “integration” in Daalu, and it’s worth keeping them straight:

• The concept — what an integration is and how it authenticates. That’s Chapter 11.
• The catalog — the per-provider reference, with credentials, scopes, and troubleshooting for each system. That’s Part VI (Chapters 36–40).
• This page — where you actually click the buttons. That’s what this chapter walks through.

If you know what you want to connect, the catalog is your destination. If you’re standing in front of the product wondering what each section does, you’re in the right place.

The three sections

The page is organized top to bottom into three sections, each a different kind of connection.

1. Guided wizards

Some systems take more than a token to connect — they need a few decisions made in order. Those get a guided wizard: a short, numbered flow that walks you through the choices and verifies the result before saving anything.

The flagship is the Source of Truth (Nautobot) wizard — a three-step flow:

1. Choose hosted or bring-your-own. Let Daalu provision a Nautobot for you, or point at one you already run.
2. Wire the connection. Supply the URL and an API token (for bring-your-own), or accept the provisioned instance.
3. Confirm and verify. Daalu makes a live test call. Pass, and the source goes green; fail, and you see the error inline with nothing saved.

Once it’s connected, your devices, sites, and intended configs flow into Operations (Chapter 19) and the reconciler starts watching for drift. The concept behind a source of truth is Chapter 14; the provider reference is Chapter 38.

Tip — A wizard never saves a half-finished connection. If you close it midway, nothing is written. Come back and start fresh.

2. Notification channels

Channels are outbound — they’re how Daalu reaches you. Unlike ingest sources, they don’t pull data in; they exist so alerts, briefings, and team invites have somewhere to go.

Two ship today:

• Email — the transactional path. Required for the team-invite flow and the default destination for digests. Configure the sending details once and every email feature works.
• Slack — connect a workspace and pick the channels Daalu may post to (#ops-alerts, #netops, and so on).

Each channel has a Configure button that opens its setup step in a modal, and a test you can fire to confirm the wiring before you depend on it. Channels define availability — which destinations exist. Routing — which alert goes to which channel — lives in Settings (Chapter 28) and is covered by the events-and-notifications model in Chapter 12. The per-provider reference is Chapter 37.

Note — Set up the Email channel early, even if Slack is your real destination. The team-invite email path depends on it, so a missing Email channel is the usual reason an invite never arrives.

3. Ingest sources

Ingest sources are adapters — connectors that pull observations from an external system into Daalu as events. Each source you’ve connected appears as a card with a Run ingest button.

Clicking Run ingest triggers an immediate pull from that source: the adapter calls the external system, normalizes what it finds into Daalu events, and drops them onto your timeline. The button spins while the run is in flight and reports back when it’s done. Most adapters also run on their own schedule once connected; the button is for when you don’t want to wait — you just changed something on the source side and want to see it reflected now.

This is the raw material for everything reactive in the product. An ingested event can:

• sit on the timeline for search and queries (Chapter 23),
• match an alert rule and become an alert (Chapter 22),
• feed the daily briefing (Chapter 18),
• or give the Assistant something to reason about when you ask a question.

The per-provider details — what each adapter pulls, how often, and what credentials it needs — live in the Part VI catalog (Chapters 36–40).

Adding a new integration

Every connection follows the same shape regardless of section:

1. Pick the type from the relevant section.
2. Fill the type-specific form — a token, a URL, a scope, or a short wizard.
3. Daalu makes a synchronous test call. Pass, and the integration appears connected. Fail, and you see the error inline; nothing is saved.

That synchronous test is deliberate. You never end up with a row that looks connected but silently isn’t — if it saved, it worked at least once.

How this page lights up the rest of Daalu

It’s worth saying plainly, because it’s the whole point: the Assistant can only see what an integration exposes, and an alert can only fire on data that came in through one. Connect nothing, and Daalu is an empty shell. Connect a source of truth and an observability stack, and the same Assistant suddenly answers “why did this device drift?” and “what’s driving CPU on this cluster?” with real evidence.

So the practical onboarding order is:

1. An ingest source or two — so events start flowing.
2. A notification channel — so the alerts those events produce can reach you.
3. A source-of-truth wizard — if you operate a network and want drift detection.

From there, the rest of the catalog is additive. Each new integration widens what the Assistant can see and what your alerts can fire on.

Next: Chapter 25 — Managed infrastructure