Workflow presets

What this accomplishes

Start from ten built-in workflow templates and customise them.

A workflow preset is a pre-built workflow the user can fork into the user’s project. The preset is a working automation; the user can customise the preset to fit the user’s specific needs. The presets are the right shape for the user to start a workflow without designing the workflow from scratch.

This guide covers workflow presets. See the Automation overview for the built-in list; the visual workflow builder is in visual workflow builder.

Current availability

This page documents behaviour verified in Miton development builds. Miton is still pre-release and is not publicly downloadable; invited beta users will receive a signed desktop build with automatic updates.

Before you start

• A Miton development build, an active project and Automation open.
• A connected model plus permission for every file, network or scheduled action in the workflow.

The ten built-in presets

Miton ships with ten built-in workflow presets:

• Weekly brief. A morning workflow that pulls the user’s calendar, summarised unread email, the weather, and the top news in the user’s industry, and writes a five-minute brief.
• Monthly report. An end-of-month workflow that pulls the month’s data, generates a report, and emails it to a distribution list.
• RSS to document. A scheduled workflow that pulls from RSS feeds, summarises with the agent, and writes a digest document.
• Social media queue. A weekly workflow that drafts five social posts based on a topic brief and schedules them via Buffer.
• GitHub issue triage. A webhook workflow that triages new GitHub issues by labels, asks the agent to summarise, and assigns to a maintainer.
• Code review digest. A daily workflow that reviews the day’s pull requests, summarises the diffs in plain English, and posts to a Slack channel.
• Status page scraper. A scheduled workflow that scrapes a status page, alerts on Slack if any component is degraded.
• Lead enrichment. A webhook workflow that fetches company info and recent news when a new row hits a spreadsheet, and writes a summary to a new column.
• Inbox triage. A scheduled workflow that reads unread email, classifies by urgency, drafts replies for the easy ones, and routes the rest to a triage folder.
• Meeting prep. A scheduled workflow that pulls attendee’s recent posts, the last few emails exchanged, and open tickets, fifteen minutes before every meeting, and gives a one-page brief.

Each preset ships with a working workflow; the user can fork the preset and customise.

The fork flow

The user opens the workflow menu; the user picks “New from preset”; the user picks a preset; the user clicks “Fork”. The preset is forked into the user’s project; the user is in the workflow editor with the preset’s nodes, connections, and configuration.

The user can edit the workflow; the user’s edits are saved automatically. The user can also use the agent to help with the workflow; the agent has access to the workflow’s content and the user’s convention memory.

The fork is irreversible. The preset is a template; the fork is a copy. The user can delete the fork; the user can also delete the preset from the workflow menu (the user cannot delete a built-in preset, but the user can delete a custom preset).

The custom preset

The user can create a custom preset. A custom preset is a YAML file in .miton/presets/<name>.yaml that specifies:

• Name — the preset’s name (used in the preset picker).
• Description — the preset’s purpose (shown in the preset picker).
• Workflow — the workflow definition (a YAML file with the same schema as the workflow’s YAML).
• Tags — the preset’s tags (used for search in the preset picker).

The user can also define a custom preset in the shared registry (the @miton/presets registry). The shared presets are available across all projects the user works on.

The custom preset is per project. The user can export the custom preset to a JSON file; the user can import the custom preset from a JSON file. The export and import are useful for sharing a custom preset across projects.

The completion checklist

The completion checklist is a list of common things the user might forget when forking a preset. The checklist is per preset; the checklist is shown in the right side of the workflow editor when the user forks a preset. The user can check an item when the user has completed it; the checklist updates in real time.

The completion checklist is a property of the preset, not a property of the workflow. The user can also add items to the checklist in the current workflow; the items are preserved for the workflow; the items are not added to the preset.

What the workflow presets do not cover

The workflow presets do not cover:

• Live collaboration on the preset — the preset is per project; the user can share a custom preset via the shared registry, but the preset is not a real-time-collaborative document.
• Preset versioning — the preset is a single version; the user can update a custom preset, but the user cannot have multiple versions of the same preset.
• Preset dependencies — the preset is a standalone workflow; the preset does not depend on other presets or on other workflows.

The workflow presets focus on the common case (a single workflow, a single preset). The less common cases are covered by the user’s existing tools.

What success looks like

The ten workflow presets are the right shape for the user to start a workflow without designing from scratch. The user picks a preset; the user forks the preset; the user has a working workflow.

The completion checklist is the right shape for the user to verify the workflow is complete. The user checks the items as the user completes them; the user can add items to the checklist for the current workflow.

The custom preset is the right shape for the user to extend the presets. The user can define a custom preset; the user can share the custom preset via the shared registry.

The presets are the most common case. The user who has a workflow that is not in the ten presets can use the visual workflow builder to build the workflow from scratch, or fork the closest preset and customise.

Common failures and recovery

• Inspect the failed run and the exact node output before replaying it.
• Confirm credentials, permissions and test fixtures belong to the active project.
• Use dry-run or step replay before starting the complete workflow again.

Related next action

Open the Automation overview to connect this task to the rest of the workflow.