Actions And Runs

Actions turn reusable logic into executable workflows. Runs and jobs provide the operational trace for what happened, what was produced, and what still needs review.

For customers, this area is where automation stops being abstract. It is where reusable logic meets real execution, human review, and operational accountability.

Core concepts

• actions define the executable behavior
• runs record each execution instance
• jobs track queue-backed progress and control state
• artifacts, contracts, and timeline views provide execution detail

Who this is for

This page is for teams that define reusable automation, execute it, or review outputs produced by actions and runs.

Where actions fit in the product

Actions are best understood as reusable operational building blocks. Teams define them once, then execute them where the workflow needs them.

Teams should understand actions in terms of outcomes, not only technical execution. A reader should understand:

• what business or review problem an action is meant to solve
• when an action should be run manually versus triggered from another workflow surface
• how the run record helps the team understand what happened after execution

Typical action lifecycle

1. Define or update an action so the expected behavior is explicit.
2. Run the action manually or from the workflow surface that needs it.
3. Watch job progress if the work is queue-backed or long-running.
4. Review the resulting output, artifacts, and timeline events.
5. Approve, retry, abort, or rerun based on the quality of the result.

What teams should decide before running an action

Before execution, teams should check:

• whether the action is still the right one for the task
• whether the current input or binding context is complete enough to produce a useful result
• whether the output will require review before wider use
• whether a retry would actually help if a previous run failed for a data-quality reason rather than a transient system reason

Runs, jobs, and artifacts

Teams should not have to infer the difference between these surfaces.

• the action defines what can happen
• the run records a specific execution attempt
• the job shows operational progress for queued or background work
• artifacts capture the output the team may need to inspect, review, or reuse

That distinction matters because users often ask different questions at each layer:

• Did we run the right thing?
• Is it still running?
• What did it produce?
• Can we trust or approve the output?

Review and decision points

The docs should frame run review as part of normal work, not as an exceptional troubleshooting step.

Teams should be guided to:

• inspect outputs before promoting them into a wider workflow
• use timeline and artifact views to understand what the run actually did
• retry only when the failure mode suggests a new attempt could succeed
• abort work when continuing would waste operator time or compute without improving the outcome

Actions in AI-assisted workflows

Some actions may invoke AI-assisted behavior or produce AI-shaped output. Customer guidance should keep the same boundary clear here as elsewhere in the site:

• execution may be automated
• review responsibility still stays with the team
• artifacts and run history help explain what happened
• approval should happen at the workflow level, not just because a job completed successfully

Common customer misunderstandings to prevent

• a successful job is not automatically an approved result
• retry is not a substitute for fixing weak input data or workflow context
• artifacts are part of the operational record, not disposable byproducts
• aborting a run is sometimes the correct operational choice, not a sign of failure

API reference

Use TrialStack API reference for exact action, run, artifact, status, retry, abort, and review-related contract details.

Read next

• AI Workflows
• Templates
• Integrations And API