Job templates
Define reusable Component execution, inputs, limits, concurrency, and retry policy.
Schedules and events
Trigger templates, Agents, or supported platform operations over time or from messages.
History
Inspect jobs, event fan-out, logs, retries, cancellation, and replay.
Choose the right primitive
Create a Job template
- Build and activate the target Component.
- Open Jobs → Templates.
- Select the Component and optionally pin a version.
- Choose the execution principal.
- Add template input under
options.input. - Set timeout and memory limits.
- Configure sensitive-history, concurrency, and retry options.
- Save the template and run a controlled test.
Inputs and history
Template input is a JSON object. Each run may supply its own structured job input, while the Component can also read stable template values. New integrations should not send JSON encoded as a string. UsehideRequest or hideResponse when an execution payload should not be retained in job history. These options reduce persisted visibility; they are not a substitute for avoiding secrets in application payloads.
Concurrency
Concurrency groups related jobs under a logical key:keyidentifies the shared bucket.limitbounds simultaneous executions in that bucket.ttlbounds the slot lease if an execution stops reporting progress.
Retry policy
Automatic job retry applies only after a job reaches terminalERROR. The failed job remains in history and a new child job carries retry lineage.
Policy fields include:
enabled;- total
maxAttempts, including the original attempt; - minimum and maximum backoff;
- exponential doublings before linear growth;
- optional concurrency bypass for automatic retry children.
Job lifecycle
- Retry creates another attempt from a failed job.
- Run now asks a still-pending job to dispatch immediately.
- Cancel requests cancellation for active selections.
- Delete / restore changes history visibility without pretending the execution did not happen.
Schedules
A Schedule combines a five-field cron expression, an IANA timezone, activation state, and one execution target.Europe/Warsaw or UTC. Avoid abbreviations such as CET or EST, which do not express daylight-saving rules reliably.
A Schedule can target a Job template, an Agent, or a supported platform operation. You can pause, resume, edit, delete, restore, or trigger it immediately. The durable Schedule definition is authoritative; the scheduling layer is responsible for delivery.
Events
An Event definition subscribes one target to a platform event type or aCUSTOM_* type. Optional filters are evaluated against the normalized event envelope before work is scheduled.
In the visual builder, enter only message-relative property paths. The UI converts them to stored message.* query fields:
mimeType and metadata.pipeline, without the message. prefix.
Built-in event families cover Storage and legacy file lifecycle, users, service accounts, and account API keys. Custom events let an application publish its own business signal.
Event metadata is searchable and bounded. Use it for routing and correlation, not as an alternate large-payload channel.
For file-driven automation, prefer the Storage event family. STORAGE_CREATED starts work after a new file has finalized; STORAGE_SYNCHRONIZED is the stronger boundary when asynchronous text statistics must be available to the first Job. The target receives { type, metadata, message }, and the Component should reload message.storageEntryId under its own service-account permissions before reading content.
Event history and replay
One triggered message creates an Event history entry. It records:- normalized type and metadata;
- resolved targets;
- scheduled executions;
- targets skipped because a filter did not match;
- replay and lifecycle evidence.
Outbound webhooks
Webhooks send an asynchronous HTTP request with a method, URL, optional headers, and optional body. You can configure retry attempts, request-detail retention, masked fields, metadata, and a static outbound network path when your integration requires allowlisting. UsemaskDetails for fields that should not be persisted in readable webhook history. Prefer resolving credentials from Secrets inside a Component when you need stronger control than a stored static header.
The Webhooks workspace shows delivery state and supports cancellation, deletion, and restore. A webhook row is an outbound attempt record, not a subscription for inbound traffic.
High-level execution flow
Production checklist
- Use a dedicated service account as the execution principal.
- Pin a Component version for controlled releases.
- Put stable values in template input and per-run values in job input.
- Set explicit timeout, memory, concurrency, and retry policies.
- Use IANA timezones and test daylight-saving transitions.
- Filter events before scheduling expensive work.
- Make replay and retry safe with idempotency keys.
- Mask or suppress sensitive request and response history.
- Monitor terminal state and retry lineage, not only dispatch acceptance.
Related guides
Events
Configure event types, filters, targets, and safe test messages.
Storage
Build governed file ingestion with ACL, retention, finalization, events, and bounded reads.
Event History
Follow fan-out evidence and replay selected messages safely.
Schedules
Configure cron, timezone, target modes, and operator lifecycle.
Outbound webhooks
Deliver asynchronous HTTP requests with retries and masked history.
Components
Build the logic executed by Job templates.
Agents
Use schedules and events as autonomous Agent triggers.
Observability
Diagnose jobs, event fan-out, and webhook delivery.
Secrets
Keep integration credentials out of template and webhook payloads.

