Create and Manage Automations

Instruction automations

Create and edit in Library

Choose Create → Automation, then choose a Space. The automation opens as an artifact, next to documents and apps. You can also make one from the artifact panel of a conversation. New automations that you make this way start paused.

Open Automations in the sidebar to find and open automations again. The editor has the instructions, schedule, model settings, connections, destination channel, and run history. You can work with Type in the conversation of the artifact.

• Save keeps the current enabled or paused state.
• Enable and Pause are separate actions.
• Save your changes before you use Test. Test starts a private test conversation. See Test Automations.
• If someone else changes the automation while you edit it, reload before you save. Your draft stays visible until you discard it.

Existing scheduled automations become artifacts the first time that you open them. Their schedule, enabled state, instructions, and run history do not change. Automations that you have not opened continue to run as before.

An artifact keeps the permissions of the automation. People and agents who could edit or operate it before can continue to do so. Archiving also stops future scheduled runs. The conversion does not change the credentials that the scheduler uses.

Automations do not support public publishing, document suggestions, or restoring document versions. Event-triggered automations keep their existing editors.

Ask Type in the Space

Describe the job in a thread. Type proposes the automation, with its trigger, schedule, destination, and connections. Confirm the proposal before Type makes it. A new automation stays disabled unless you explicitly ask Type to start it.

Use the CLI

• type-cli scheduled-actions list --space <space> lists scheduled automations. The list includes older automations that are not artifacts yet.
• get <task-id> returns the definition, the artifact link when there is one, and an editVersion for later edits. Listing and reading do not convert an automation.
• type-cli scheduled-actions open <task-id> --space <space> opens the artifact in your browser. It converts an older automation when necessary and keeps its task ID. Add --no-open --json to get the link without a browser.
• Update, enable, and disable check the version that you read before the change. Pass --expected-version <editVersion> to reject a change if another person or agent edited the automation after your read. On a conflict, read the latest definition and review the changes before you try again.
• delete <task-id> archives and disables the automation. It keeps the run history.

The CLI follows the existing automation permissions.

Code automations

There are two ways to make a code automation:

Method	Best for
Type CLI	Code in a folder on your computer, version control, and fixtures.
Type AI in a Space	Short automations. Describe what you want, and Type writes and deploys the code.

Both methods use the same deploy checks, and both make the same kind of automation.

Deploy with Type CLI

type-cli automations deploy ./my-automation --space engineering

The CLI prints each stage. When the deploy is active, the automation is enabled. See CLI Reference.

To update the code, change the files and run the same command again. Type updates the same automation, because .type/project.json has the same project ID.

Ask Type AI to write it

In a Space, describe the automation. For example:

When someone posts “deploy failed” in #ops, reply in the thread with the runbook link.

Type writes the code and deploys it with the create_task tool. The result has a projectId. To change the code later, ask Type to update the same automation.

Differences from the CLI:

• The AI deploy has no fixtures. The first real event is the first test.
• The AI checks access with the access of the automation, not with its own access in the thread.

Update the code

• A successful deploy replaces the active revision.
• A failed deploy keeps the active revision.
• Only the person who created the automation can deploy to it.
• If the code is the same, Type uses its earlier validation.
• Checkpoints stay if the subscription keys stay the same.

Pause, resume, and delete

type-cli scheduled-actions disable <automation-id> --space <space>   # pause
type-cli scheduled-actions enable <automation-id> --space <space>    # resume
type-cli scheduled-actions archive <automation-id> --yes              # archive
type-cli scheduled-actions delete <automation-id> --permanent --yes   # delete permanently

• A deploy enables the automation. To keep it paused, disable it again after the deploy.
• Deleting an automation does not delete a shared webhook registration. Other automations can still use it.

Upgrades

Type records the automation API version that the code was written for. Type always runs saved code with the current SDK. When the API changes, Type marks older automations:

Status	Meaning
upgrade_available	The automation still runs. Upgrade it when you next change the code.
unsupported	Type no longer runs it. The next run fails and starts a repair. You cannot enable it until you upgrade it.

To upgrade, change the code for the current API, then deploy. Deploying new code records the current version. You cannot set the version yourself.

Recover an interrupted deploy

If the CLI loses its connection, the deploy can still finish. Do not deploy again at once. Read the result:

type-cli automations deployment <deployment-id> --space <space> --follow

The deployment ID is in .type/deployment.json. A deploy that does not activate in 10 minutes stops.