HiveshipDocs

Workflow automations

Automations run a small trigger → action rule whenever something happens in your workspace — an issue is created, a status changes, an agent finishes a session. Instead of nudging issues along by hand, you describe the behaviour once and Hiveship applies it for you, server-side and in the background. Automations are a Pro feature; on the free plan the Automations page stays visible with a Pro upgrade prompt so you can see what it does before you upgrade.

Anatomy of a rule

Each rule is built from four parts in the rule editor (Workspace → Automations → New rule):

  • Trigger — the event that starts the rule.
  • Condition (optional) — require a field on the triggering event to match a value before the rule runs. Leave it blank to fire on every event of that type.
  • Action — what Hiveship does when the rule fires.
  • Scope — apply the rule across the whole workspace, or limit it to a single project.

Give the rule a name, save it, and it starts running. Every rule has an active toggle, so you can pause one without deleting it and switch it back on later. Creating, editing, and deleting rules is reserved for workspace owners and admins; members and viewers can see the rules that are running but not change them.

Triggers

A rule fires on one of these workspace events:

  • Issue created — a new issue lands anywhere in scope.
  • Issue status changed — an issue moves between workflow statuses.
  • Agent session completed — an agent finishes working on an issue.
  • Agent session errored — an agent run fails.

The last two are what make automations agent-first: you can react to what your agents do, not just what people do — for example, move an issue to a review status the moment an agent finishes, or ping a human when an agent run errors out.

Actions

When the trigger (and condition, if set) matches, the rule runs the action you configured:

  • Change status — move the issue to a workflow status you pick.
  • Assign user — set the assignee to a teammate.
  • Delegate to agent — hand the issue to an AI agent. This both assigns the issue and queues an agent session, so the work starts without anyone clicking through the delegation flow by hand.
  • Add label — tag the issue with a label.
  • Send notification — notify a teammate with a title and optional body.

How rules run

Automations execute on the server, asynchronously — the rule is queued and runs a moment after the triggering event, so it never blocks the action that set it off. A rule that fails is logged and skipped; it won't stall issue creation, status changes, or anything else happening in your workspace. Actions a rule takes are attributed to the automation in the activity feed, so it's always clear that a status move or delegation came from a rule rather than a person.

Because triggers include agent-session events and one of the actions is "delegate to agent," rules can chain: a human creates an issue, a rule delegates it to an agent, and a second rule moves it to review the moment that agent finishes. That's the agent-first loop automations are built for.

Example rules

  • When an issue is created in the Bugs project, send a notification to the on-call engineer.
  • When an agent session completes, change status to "In Review" so a human picks it up.
  • When an issue is created in the Triage project, delegate to agent to start the work automatically.
  • When an agent session errors, assign the issue to your triage lead so a human takes over.

Next steps

PreviousProjectsNextSearch
Edit this page on GitHub