A Hex project is not just a notebook. It has input parameters, recent run history, output state, and often a decision that depends on what the next run will publish. Strawberry can list projects and runs, inspect a project’s accepted inputs, check the status of a run, and trigger a real project run when the team has reviewed the target and its publication impact.
01
Know what a project accepts before you run it.
A project run is more reliable when its input schema and intended parameters are clear first.
The Hex project detail operation exposes the accepted input parameters, allowing Strawberry to prepare a precise run request instead of relying on a guessed notebook setup.
02
Use run history to diagnose the current result.
A failed run, a completed result, and an old published output can mean very different things.
Strawberry can list recent runs in order, inspect a particular run’s state and timestamps, and help the data team see whether the next move is to wait, inspect, or rerun.
03
Treat published output as a real consequence.
Triggering a Hex project run is a real operation, and choosing to update published results can overwrite the published app output. Strawberry can prepare that action, but the team should verify the project, parameters, and publication setting before it starts.
04
Make recurring data checks auditable.
Many reporting projects need a consistent run check rather than a manual hunt through notebooks. Save the project IDs, parameter rules, and output checks as a skill, then use a routine to prepare the run status and exceptions for the data owner.
Yes. Native Hex operations can list workspace projects, retrieve a project’s detail and input schema, list recent runs, and inspect a specific run’s status.
Yes. It can trigger a real project run. Confirm the project and input values first, because the operation has real execution consequences.
A project run can be configured to update published results, which overwrites the published app output. Review that setting explicitly before approving the run.
Yes. Save the target projects and exception rules as a skill, then schedule a routine that prepares a status brief without automatically rerunning projects.
Approve requested workspace access, keep project runs behind review, and verify the exact output impact before initiating a run.