Build visual workflows that chain audits, agents, and alerts — run them on demand or on a schedule.
Workflows let you turn a repeatable process — a weekly visibility check, a citation-gap review, an audit-then-alert chain — into a visual graph that runs on demand or on a schedule.
Note: Workflows is in private beta for Pro, Ultra, and Enterprise plans. If you don't see Workflows in the sidebar, contact support to request access.
Prompt-scoped nodes (Citation Patterns, Scrape AI engines) analyze one monitored prompt. Pick which one in the node's Context tab — or leave it on Automatic to use the first prompt from a connected Monitored prompts node.
Every workflow starts with exactly one trigger node. Connect nodes left to right — each node's output flows into the nodes it connects to.
The palette groups nodes into six categories:
| Category | What it does | Examples |
|---|---|---|
| Triggers | Start the workflow | Manual run, Schedule, Visibility drop, New citation |
| Data & Sources | Read your Vizzybl data, or a connected tool | Visibility stats, Citations, Monitored prompts, Latest audit, Search Console, GA4, WordPress posts, AI crawlers, Workfront projects |
| Agents | Run an AI agent | GEO audit, Brand Intelligence, Content Authority, Brand Protection, llms.txt |
| Recipes | Ready-made composite reports | Weekly Pulse, Citation Gap, Engine Scorecard, Source Authority |
| Logic & Control | Branch, wait, or fan out | Condition, Switch, Wait, Parallel, Merge |
| Actions & Outputs | Deliver results | Channel message, Email, Action Board card, Trello/Workfront, Publish to WordPress, Call a webhook, Dashboard notification |
Agent nodes charge the same credits as running the action anywhere else in Vizzybl. A failed run never double-charges — retries reuse the original charge, and a step that fails after charging is refunded automatically. Steps that read or write a connected tool cost nothing.
Steps that use a tool you've connected in Settings → Connections all behave the same way: if the tool isn't connected, needs reconnecting, or isn't on your plan, the step is marked skipped with the reason and the rest of the workflow carries on. A workflow never fails because of something you fix in Settings.
| Tool | Read | Write | Plan |
|---|---|---|---|
| Search Console | Top queries, top pages | — | Pro |
| Google Analytics 4 | AI referral traffic, engagement overview | — | Ultra |
| WordPress | List posts | Publish a post, update a post | Ultra |
| Cloudflare | AI crawlers, crawled pages, crawl trend | — | Pro |
| Workfront | Current projects | Create a task, set a task's status | Pro |
| Keyword research | AI search volume, AI top domains, AI share of voice | — | Ultra |
| Anything else | — | Call a webhook | Pro |
WordPress. Publishing creates a draft unless you change Publish as. Content comes from the step's own setup, or from whatever the previous step produced. If you've connected more than one site, choose which one in the step's Site setting — a workflow will never guess between your sites. Republishing after a retry can't create a duplicate post.
Cloudflare. These steps read the AI-crawler data Vizzybl already collects for the AI Crawlers dashboard, so they cover a trailing 28 days and can be up to a day old — each step reports the exact window it used. AI-crawled pages needs the beacon or Logpush ingest; the Cloudflare API method doesn't report individual pages.
Keyword research. Three steps answer what people actually ask AI engines, which domains those engines quote, and how often a domain is mentioned across them. Pick a location from the list — the research API only recognises those, and an unsupported one would quietly return US figures. These are the only data steps that cost credits — 1 credit per step, because they call a paid research API. If the API has no data for your keywords, the step is marked skipped and the credit is refunded rather than spent. Give it keywords in the step's setup, or connect a Monitored prompts step and it will use those.
Call a webhook. Sends the run's data to any HTTPS endpoint — Zapier, Make, n8n, or your own service — so you can reach a tool Vizzybl has no step for. By default it posts everything the previous steps produced; set a body to send something specific. Private and internal addresses are refused. If the endpoint needs a key, put it in the URL: don't paste secrets into step settings, because they're stored with the workflow and visible to everyone in your workspace.
A connection carries the whole output of the node it leaves, so most workflows need nothing more than a line between two nodes. Select a connection to open its inspector when you need more control.
Branches. A connection leaving a Condition node takes either the true or the else side — pick one in the inspector. Exactly one connection should be else, or the else path never runs.
A connection leaving a Switch node carries the value it matches — type weekly to follow the branch where the switched value is "weekly". Use default for the connection that should run when nothing else matches, including when the value is missing.
Important: on a Switch, a connection left blank is not the default — it only runs when the value is literally "true". Set a value, or use
default.
Field mapping. By default a step reads whatever it needs from everything upstream. When two upstream nodes offer the same field, or a step needs a value from deeper in an output, open the connection's Mapping tab and point the field at an exact path — for example prompts.0.promptId. The editor shows the paths seen in the last run and tells you whether a path resolves.
Use Run test in the editor to execute the graph exactly as it appears on the canvas — the draft is saved automatically first, so a test always runs what you see. Manual and scheduled runs use the last published version.
The run button shows what the run could cost, for example Run test (up to 15 credits). That is always an upper bound: steps that skip don't charge, only one side of a branch runs, and a GEO audit is billed when the audit itself runs.
To pass one-off values into a run, open the inputs control next to the run button and add key/value pairs. They arrive on the trigger node's output, so any downstream step can read them.
Watch it run. While a run is in flight the canvas shows it live: each node gets a status dot and a coloured border, and the top bar shows the current step, progress, and credits used so far. Cancel run stops it — steps already finished stay finished, and any credits held for a step that never completed are released. A run started by a schedule or an event lights up the canvas the same way.
Select any node and open its Output tab to see exactly what that step produced. Each run also appears in Runs with per-node status, duration, output, and the credits it used; Show on canvas pins an older run so you can inspect it against the graph, and Unpin run returns to following the latest.
If a node fails, open the run and use view error to see exactly which node failed and why. Nodes retry automatically on transient failures. A step shown as skipped completed without doing its work (for example, an email or chat step with nothing configured to send to) — the skip reason appears next to the step.
Publishing keeps a snapshot. Open Versions in the editor to see every published version with who published it and when, and what changed between it and the version before — nodes added or removed, configuration changed, connections changed.
The editor's top bar shows draft differs from v3 whenever the canvas has unpublished changes.
Use the ⋯ menu on any row in the workflow library to Duplicate or Delete.
A duplicate arrives as a disabled draft called "… (copy)" with no run history, and it never inherits a schedule — so copying a live scheduled workflow leaves the original firing and gives you a safe copy to edit.
The on/off toggle controls scheduled execution: off pauses the schedule without deleting anything, on resumes it. Edits you publish take effect from the next scheduled run.
Important: Schedule times are UTC. A workflow set to 09:00 runs at 09:00 UTC regardless of your local timezone.
Workflows can also start themselves when something changes — no schedule needed:
sovDelta, currentSov, and previousSov from the trigger.reddit.com) to watch one source. Downstream nodes can read domain and promptId from the trigger.Publish the workflow and turn it on — event-triggered workflows fire at most once per event (a given day's snapshot, or a given new domain), so retries and re-checks never run them twice.