Create or import an automation

Open Automations to find the workflows available in your organization. Only the Owner, Admin and Developer roles see this section and manage its automations. Start with a built-in automation when it matches your task, or create a draft you can test before making it live.

Search by name or slug. For example, enter Triage to compare the shipped triage workflows.

Choose a starting point

Each row shows the automation’s name, project bindings, version count and deployed version, or Not deployed. Beside it, Trigger says whether the automation starts on its own, and underneath which kind of trigger it has (Schedule, Webhook or Platform event). Enabled means the trigger starts runs, Paused that it turned itself off after repeated failures, Off that it starts nothing until someone turns it back on, and Not live that it waits for a deployed version. Manual, with By hand, API or MCP underneath, marks an automation without a trigger: it runs whenever someone starts it. When the list cannot tell, for example during an update, it shows Unknown; General always shows the trigger itself. Open it on the Editor tab to inspect the workflow. General holds its trigger and its projects: Projects controls which boards can use it; without project bindings, it serves the organization. Projects offers only the projects you can open, and saving keeps any binding to a project you cannot see. An automation bound only to such projects does not appear in your list. The Version selector beside the tabs shows its saved history; Runs shows recent executions. Select a row’s version count, or Version history in its row menu, to open Versions: every saved version and every deployment.

The Create automation menu offers three routes:

Shipped automations are already installed when the organization is created. They still need configuration and a deployed version before automatic use. Follow the workflow editor to test inputs, inspect results and deploy deliberately.

Import a package

A pack contains the required workflow.yml, an optional automation.yml manifest and, optionally, skill bundles:

review-invoices/
├── workflow.yml
├── automation.yml
└── skills/
    └── invoice-rules/
        ├── SKILL.md
        └── references/
            └── checklist-rules.md

1. 1

   Select the files

   Choose Create automation > Upload package. Upload the workflow and optional manifest as individual files, or select one .zip containing the pack. Use a zip when carrying skills; upload that archive on its own. Markdown notes outside skills/, dotfiles and build leftovers such as node_modules/ and __pycache__/ are ignored.

2. 2

   Choose the destination

   Under Install into, choose Organization or an existing project. A manifest declaring scope: project requires a project. Installing an existing automation into another project adds that binding; it does not remove previous ones. You can adjust the full set later under Projects on the automation's General tab.

   

3. 3

   Validate and save

   Choose Upload package and resolve any reported document, manifest or skill issues. When the workflow fails the checks, the dialog says This package doesn't pass the checks. and lists each problem as the editor's Problems list does: what is wrong, its code and how to fix it. Correct the file and upload it again. Validation completes before the upload writes the automation and carried skills. A successful upload creates a draft; uploading the same automation again appends a version and preserves its history.

4. 4

   Review before deployment

   Choose Later to inspect and test the draft in the editor. The success dialog also offers deployment of the numbered version. Uploading alone does not change the live version. Configure required credentials and check the supplied skills before deploying.

Keep a zip within 20 MiB compressed and 20 MiB expanded, with at most 500 files, 2 MiB per file and 20 skill bundles. If rejected for size, remove generated artifacts and split unrelated material into separate skills rather than increasing compression alone.

Resolve skill conflicts

The manifest’s skills list must match the folders carried under skills/: undeclared folders and declared-but-missing bundles are rejected. Each bundle needs valid SKILL.md frontmatter with a name matching its folder. Carried skills follow the skill library's rules: a new skill belongs to the person uploading the package, and a replacement keeps its owner or belongs to the uploader if it had none. New or changed team lists may name only teams the uploader may share with; existing lists can stay unchanged. Tale checks every carried skill's audience before installing any of them.

# automation.yml
name: Review invoices
skills:
  - invoice-rules

New bundles are installed into the organization’s skill library, and identical bundles remain unchanged. Different content pauses the upload and lists the affected slugs. Confirm replacement only after reviewing them: the package replaces those shared bundles, and the previous SKILL.md remains in each skill’s history. No automation or skill is written before that confirmation.

A workflow may also refer to library skills it does not carry. If one is missing, the upload reports a warning; install an accessible bundle before running the agent that needs it. A saved draft does not prove all its dependencies are ready.

Configure a project through package forms

A manifest can declare forms that appear when someone selects the automation’s task template. Values belong to the project, so two projects can use the same automation with different policies.

# automation.yml
settings:
  folder: Setup
  forms:
    - file: validation-policy.yaml
      title: Validation policy
      required: true
      fields:
        - key: method
          label: Validation profile
          type: select
          default: strict_rules
          options:
            - value: strict_rules
              label: Strict checklist

A required form appears before the task’s own fields if that project has not been configured. Save and continue writes the forms and proceeds to task creation. Later, Settings reopens them as tabs; a dot marks unsaved changes, and Save writes every changed form. Closing with unsaved edits asks for confirmation. A form’s description stands above its fields; when it runs past three lines, its beginning shows with Read more to open the rest.

Saving replaces the form’s flat YAML file, such as Setup/validation-policy.yaml. Existing values prefill the form, including values uploaded by hand. Supported field types are text, number, boolean and select; stored values are strings. Text fields can specify a pattern, and per-entry i18n blocks localize titles, labels, help and options. Keep nested structures and lists in separate files the workflow reads.

Supply reference files through an upload form

An upload form manages files directly instead of producing YAML:

settings:
  folder: Setup
  forms:
    - kind: uploads
      title: Reference documents
      subdir: reference
      accept: ['.pdf', '.json']
      match: '\.(pdf|json)$'
      requireFolder: true

subdir chooses a subfolder of the settings folder. accept limits extensions offered by the picker; match filters listed names case-insensitively and rejects uploads that would not appear. With requireFolder: true, select or create a subfolder before uploading, for example one per reporting period.

Uploads apply immediately and have no Save action. They never block task creation. Runs read the folder’s current contents, so finish preparing the reference set before starting work that depends on it.

Define what the reviewer should receive

The manifest can name deliverables in the task’s Outcome area. Declared files stay in the specified order; other attachments and working files remain under Files.

subjects:
  task:
    outcome:
      files:
        - return.xml
        - report.md
        - name: audit-summary.md
          optional: true

A required file appears as Not ready yet until a run files it. An optional file appears only once it exists. Patterns support * and ?, such as return-*.xml. Without declarations, the outcome shows all files filed by runs, newest first. Use a short explicit list when the reviewer needs to distinguish the final report from supporting work.

Ask before an approval that decides more

Approve closes the task in one click. When approving means more than closing the task, declare that consequence, for example when an integration reports the approval to a client as a filing. Approve then asks first and shows your sentence:

subjects:
  task:
    review:
      requestChanges: true
      approve:
        confirm: Approving tells the client this return has been filed with the tax authority. Approve only after you have filed it.
        i18n:
          de:
            confirm: Mit der Freigabe erfährt der Kunde, dass diese Abrechnung bei der Steuerverwaltung eingereicht ist. Gib sie erst frei, wenn du sie eingereicht hast.

Without approve, Approve stays a one-click close. Translate the sentence under i18n; a locale without its own sentence uses its base language, then the English one.