Author a preset

A preset is a named step chain plus an input schema. It lives in JobPreset (in packages/platform-domain) — the single source of truth that both the preset list and the runtime read, so they can’t drift.

1. Declare the step chain

Add your preset to the JobPreset mapping with its ordered steps. Use only registered step names — the StepRegistry resolves them at runtime, and an env-gated step simply won’t run if its dependency is unconfigured.

2. Define the input schema

Each preset carries an InputFieldSchema per input: type, required, label, and an optional default. A default may itself be a placeholder:

• ${env:KEY} — resolved server-side from the environment (e.g. ${env:NOTION_DATABASE_ID}).
• ${input:…} — supplied per-schedule, so thresholds can be tuned after seeing real data.

Because CreateJobUsecase resolves steps and inputs server-side, a client only sends the preset name + any inputs.

3. Use it

await client.jobs.startWorkflow('myPreset', { /* inputs */ })
// or schedule it
await client.jobs.createSchedule({ slug: 'my-preset-daily', preset: 'myPreset', cron: '0 8 * * *' })

If your preset needs a step that doesn’t exist yet, implement it as a new IWorkflowStep — see Extend the platform.