Automation
Automation simplifies repetitive tasks and enforces behavior or data handling based on defined conditions. The shape of every rule is the same: trigger → conditions (optional) → actions.
Examples
Always assign a manager to new employees — an "Object created" trigger on the Employee type, a
condition of `Manager IS EMPTY`, and an action assigning the Manager reference attribute to
a default manager.
Mark a product out of stock automatically — an "Object updated" trigger on the Product type,
an "Attribute changed" condition on Quantity (from any value to 0), and an action setting Status
to "Out of Stock".
Terminology
- Rule (Automation Rule) — the container: name, description, and the trigger/conditions/actions it joins together.
- Trigger — the system change that starts evaluating the rule.
- Condition — what must be true for the rule to proceed.
- Action — what happens once the trigger fires and conditions pass.
Configuring a rule
Create rules at the workspace level (Workspace settings → Automations) or the type level (open a type → Automations), then name the rule and configure its trigger, conditions, and actions.
Triggers
Every trigger is scoped to a type. Supported triggers: Object created, Object updated (an attribute's value changed), Object deleted, Comment added, and Scheduled (a cron expression, evaluated in UTC).
| Cron | Meaning (UTC) |
|---|---|
0 10 * * ? * | 10:00 every day |
0 18 ? * MON-FRI * | 18:00 every Monday–Friday |
0 8 1 * ? * | 08:00 on the 1st of every month |
0/15 * * * ? * | Every 15 minutes |
0/5 8-17 ? * MON-FRI * | Every 5 minutes, Mon–Fri, 08:00–17:55 |
A scheduled trigger targets every object of the chosen type unless narrowed with a StarQL filter, evaluated each time the schedule runs.
Run as — actions run as a user: by default whoever triggered the rule (for a scheduled rule, its creator), or a specific user you choose instead — useful so, say, every automated comment is attributed to one consistent account rather than whoever happened to edit the object. The chosen user must have access to the rule's space, and the rule can only do what that user is permitted to do.
Conditions
Zero, one, or many conditions can be attached; with more than one, all must match (AND
logic).
- Delta match — matches an attribute's change from one value to another. Both the "from" and "to" side can be Empty, Any (including empty), or a specific Value.
- StarQL filter — the triggering object must match a given StarQL query.
Actions
The number of actions your workspace can run per month is set by your subscription (see credits below).
| Action | What it does |
|---|---|
| Set attribute | Updates an attribute on the triggering object. |
| Set referenced attribute | Updates an attribute on a referenced object. |
| Transition workflow | Moves a workflow attribute to a new state. |
| Create object | Creates a new object of any type, optionally pre-populated. |
| Send email | Sends an email with a customizable recipient, subject, and body — supports placeholders. |
| Send Slack message | Posts a message to a Slack channel, and to people in Slack, with the Starhive app — supports placeholders. See below. |
| Web request | Sends an HTTP request (GET/POST/PUT/PATCH/DELETE) to an external URL, with custom headers (stored encrypted) and an optional JSON or text body — supports placeholders in the URL and body. |
| Add comment | Posts a comment (external or internal) on the triggering object. |
| Invoke Nova agent | Hands the triggering object to a Nova agent with an instruction you provide. The agent must have its Automation surface enabled in the agent builder to appear in the picker. |
Email recipients can be a specific workspace user, the current user (whoever triggered the rule), everyone watching the object, a User/Email-type attribute (on the object or a referenced object), or a manually entered address. There's no cap on the number of recipients.
Send Slack message
Posts a message with the Starhive app for Slack when the rule runs, once per triggering object. It's listed last among the actions, below a line. The Starhive app must be installed in a Slack workspace that uses your Starhive workspace.
- Channel: paste the channel's link (Copy link on the channel's name in Slack, or the channel's address in the
browser) or its ID. Invite the app to the channel first: type
/invite @Starhivein it. - People: the same choices as Send email's recipients. Each person gets the message in a direct message from the Starhive app, found in Slack by their email address. A message needs a channel, people, or both.
- Message: up to 3,000 characters, with placeholders. Format it as in Slack:
*bold*,_italic_,~strikethrough~,`code`,> quote,<https://example.com|link text>, and<!here>to notify the channel. The action posts once per triggering object, so use<!here>sparingly: a bulk change would notify the channel for every record. Values from the record are shown as they are, so they can't mention or link anything. A link to the record is added below the message, unless you place it yourself with{{object.url}}.
The action fails, with the reason in the rule's log, when nobody got the message or the app or the channel is the problem: no Slack workspace uses this Starhive workspace, the app isn't in the channel, or the channel doesn't exist, or nobody in Slack has a person's email address. Someone who isn't in Slack doesn't fail a message that others got.
Placeholders
Placeholders insert values from the triggering object into an action, using {{placeholder}}
syntax — supported in Send Email, Send Slack message, Web Request, Create Object, Set Attribute, and
Set Reference Attribute.
| Attribute kind | Example | Result |
|---|---|---|
| Basic | {{Title}} | The Title value |
| Reference | {{Manager.name}} / {{Manager}} | The referenced object's name, or the reference itself (for setting another reference attribute) |
| User | {{Assigned.name}} / {{Assigned.email}} / {{Assigned}} | User details, or the value itself for setting a User attribute |
| Workflow | {{Status.name}} / {{Status}} | The state's name, or the value itself for setting a Workflow attribute |
| Location | {{Office.address}} / {{Office}} | The address, or the value itself |
| Date/time | {{DueDate.user-friendly}} / {{DueDate}} | A readable date, or ISO format |
| Meta | {{object.url}} / {{object}} | A link to the object, or the object itself (for setting a reference field) |
| Current time | {{now}} / {{now+7d}} / {{now+7d.date}} / {{now.user-friendly}} | Now, an offset, an offset date-only, or a readable "now" |
| Date offset | {% date_add({{Due date}}, -2d) %} / {% date_add({{now}}, +7d) %} | A computed date offset from another placeholder |
StarQL-based placeholders resolve reference attributes dynamically via a StarQL query, for Create Object, Set Attribute, and Set Reference Attribute actions.
Credits and usage
Each workspace's subscription includes a monthly automation credit allowance, renewing on the 1st and not carrying over. A credit is consumed per action executed — not per trigger evaluation, and not at all if no conditions matched.
- A rule with no conditions met costs nothing.
- A rule with two actions (e.g. Set Attribute + Send Email) that both fire costs 2 credits.
- A scheduled rule matching 20 objects, running 2 actions on each, costs 40 credits for that run.
Track usage at Settings → Admin and Security → Usage and Limits. Once the monthly limit is hit, automation pauses until the next renewal — or upgrade your plan for more quota.
Auditing
Every time a rule is triggered, a log entry records which rule ran, whether its conditions were met, and the outcome of each action. View it from the global automation page, or from a specific rule's ⋯ menu.
Show details on a log entry lists the conditions and actions of that run. A failed action says why it failed, under its description:
- When the action set a value its attribute doesn't take — an option deleted since the rule was written, say — the line names the attribute and the value, followed by Check this action's values in the rule, then run it again.
- When the action sets an attribute the type no longer has, the line says so.
- Otherwise the line gives the reason the action reported, such as a refused HTTP request. An error Starhive didn't expect reads An unexpected error occurred.
A condition that couldn't be evaluated shows its reason the same way.
When any part of the run failed, Ask Nova why it failed appears next to Actions executed. It closes the details and opens a new Nova conversation that asks why the rule failed and how to fix it. The question includes the rule, the run, and the failure reasons from the log, so you don't have to copy them over. A conversation you already had open stays in your history. Like Ask AI, the button is only shown while the workspace's subscription is active.
When an execution fails, the people who can fix the rule are also notified in their inbox and by email: the rule's creator while they still have access to the rule's space, otherwise the owners of the space, otherwise the owners of the workspace. A rule is reported once per streak of failures — again only after it has run successfully and fails anew, and at most once an hour — so a rule that breaks on a busy type does not become a notification per event. Editing the rule resets this. The notification links to the rule's execution log; the Automation failures row under Settings → Notifications turns it off per channel.
Permissions
| Action | Rule's creator | Space member | Space admin/owner* | Workspace admin/owner |
|---|---|---|---|---|
| Create rule | — | ✓ | ✓ | — |
| View rule | ✓ | — | ✓ | ✓ |
| Edit rule | ✓ | — | ✓ | — |
| Enable/disable rule | ✓ | — | ✓ | ✓ |
| Delete rule | ✓ | — | ✓ | ✓ |
* Of the type the automation rule is configured on.