Gate a Dashboard Publish on a Sifflet Rule

Publishing a dashboard and checking its data are usually two unrelated schedules, and the publish always wins the race. This blueprint inverts the order: io.kestra.plugin.sifflet.RunRule runs first, and the publish step sits behind it in the same Kestra execution. Kestra's sequential task semantics do the gating, a task that fails stops the flow, so a rule run that cannot launch means the publish never fires and Slack gets a block alert instead of a success message.

How it works

1. run_gate_rule (io.kestra.plugin.sifflet.RunRule) authenticates with the API key, targets your tenant through baseUrl, and launches a run of the guard rule, typically a freshness or volume check on the tables the dashboard reads.
2. If the rule run fails to launch, because the API rejects the call, the rule is misconfigured, or the tenant is unreachable, the task fails and Kestra skips everything after it.
3. publish_dashboard stands in for your real publish step, a Log task here so the flow runs anywhere. It executes only when the gate task succeeded.
4. notify_team posts the rule run status and HTTP code to Slack on the happy path; the errors block posts a distinct BLOCKED alert when the gate stops the flow.
5. A disabled-by-default Schedule trigger runs the gate and publish together at 06:30.

What you get

• A publish step that structurally cannot run without its quality gate, enforced by task ordering rather than team discipline.
• Block alerts that name the flow and execution, so the investigation starts in one click.
• The rule run status, HTTP code, and raw API response as flow outputs for auditing every publish.
• A pattern that works for any publish target, swap the stand-in for a Hex run, a Tableau refresh, or a reverse ETL sync.

Who it's for

• Analytics engineers who have shipped a dashboard on top of a half-loaded table exactly once and do not want a second time.
• Data platform teams formalizing "check before publish" as pipeline structure instead of a runbook step.
• BI owners who need an audit trail showing every publish was preceded by a rule run.

Why orchestrate this with Kestra

Sifflet detects problems, but detection on its own schedule cannot stop a publish that runs somewhere else. Kestra turns the rule run into a hard dependency: the publish task literally waits behind it, failures produce a distinct block alert, and the execution history records the gate and the publish as one auditable unit. Note that the task gates on the rule run launching successfully; for incident-level verdicts on the results, pair this flow with Sifflet's own alerting on the rule.

Prerequisites

• A Sifflet rule guarding the dashboard's source tables, and its rule ID.
• A Sifflet API key with permission to run rules.
• A Slack incoming webhook for publish confirmations and block alerts.

Secrets

• SIFFLET_API_KEY: Sifflet API bearer token used to run the rule.
• SIFFLET_BASE_URL: base URL of your Sifflet tenant API.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

1. Add the SIFFLET_API_KEY, SIFFLET_BASE_URL, and SLACK_WEBHOOK_URL secrets to your Kestra namespace.
2. Set the rule_id input to the rule that guards your dashboard and execute the flow.
3. Confirm the Slack message shows the gate ran, then replace publish_dashboard with your real refresh and enable the daily trigger.

How to extend

• Replace the stand-in publish with a Hex project run, a Tableau extract refresh, or any BI task, and keep it behind the gate.
• Chain the gate directly after your ingestion, as shown in the Sifflet rule after load blueprint, so load, check, and publish share one execution.
• Guard the publish with several rules at once by fanning out first, as shown in the Sifflet rule pack fan-out blueprint.
• Add retry on the gate task to ride out transient API errors without blocking the publish unnecessarily.

Links

• Sifflet plugin documentation
• Sifflet documentation