Parameterized Regional Reports from One Hex Notebook

Four regions usually means four copies of the same notebook, each drifting out of sync with the others until EMEA's revenue definition no longer matches AMER's. This blueprint keeps one Hex project and lets Kestra do the multiplying: io.kestra.plugin.core.flow.Loop iterates over an inline list of region codes, and each iteration calls io.kestra.plugin.hex.projects.Run with the region passed through inputParams, so the notebook recomputes and publishes once per market from a single definition.

How it works

1. A flow-level regions variable holds the region codes, so the loop and the summary count read from the same list.
2. per_region (io.kestra.plugin.core.flow.Loop) iterates the list; inside it, run_region calls the Hex API with inputParams set to {region: item.value}, mapping each loop value onto the notebook's region input parameter.
3. wait: true makes every iteration block until that region's run reaches a terminal state, so a failed region stops the flow instead of silently publishing a partial set.
4. summarize posts to Discord with the region count computed as {{ vars.regions | length }}, and the errors block posts a distinct alert whose execution view shows exactly which region failed.
5. A disabled-by-default Schedule trigger publishes the full set every Monday at 07:00.

What you get

• One notebook definition serving N markets, with zero copy-paste drift between regional variants.
• Per-region run isolation: each iteration has its own status, timing, and run URL in the execution view.
• A publish that is all-or-alerted, never a silent partial set of regional reports.
• A region list you extend by adding one line, not by cloning a project in Hex.

Who it's for

• Analytics teams maintaining per-region or per-customer variants of the same report.
• Data platform engineers consolidating a folder of near-identical Hex projects into one parameterized notebook.
• Anyone whose Monday starts with manually re-running the same notebook with different dropdown values.

Why orchestrate this with Kestra

Hex parameterizes the notebook; it does not enumerate your regions, sequence the runs, or tell anyone when the set is complete. Kestra owns the list, fans the runs out with Loop, waits on each publish, and reports one summary with a count derived from the same variable the loop consumed. Adding a fifth region is a one-line change in the flow, and the execution history shows every region's run individually.

Prerequisites

• A Hex project that exposes a region input parameter.
• A Hex API token with permission to run the project.
• A Discord incoming webhook for the publish summary.

Secrets

• HEX_API_TOKEN: Hex API token used to run the project.
• DISCORD_WEBHOOK_URL: Discord incoming webhook URL.

Quick start

1. Add the HEX_API_TOKEN and DISCORD_WEBHOOK_URL secrets to your Kestra namespace.
2. Point the project_id input at a Hex project with a region input parameter and execute the flow.
3. Watch the four runs complete in order, check the Discord summary, then edit the regions variable to match your markets and enable the weekly trigger.

How to extend

• Rename or add keys under inputParams to match your notebook's parameters, for example a reporting date alongside the region.
• Chain the loop behind a real warehouse load, as shown in the refresh-after-warehouse-load blueprint, so every region recomputes on fresh data.
• Replace the inline list with a query result or an API call so the region set is data-driven instead of hardcoded.
• Post one Discord message per region from inside the loop if consumers per market want their own notification.

Links

• Hex plugin documentation
• Hex documentation