Automation

Automation moves work out of interactive requests and gives it a durable operational history. RevoEngine separates reusable definitions from individual executions.

Read Jobs and durable execution for concrete patterns, instance-controlled quotas up to 59 minutes and 4 GiB, and guidance on when a Job is the wrong primitive.

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

Primitive	Use it when
Job template	The same Component should run repeatedly with consistent policy.
Job	You need one durable execution and its status, result, logs, and lineage.
Schedule	Work should run from a five-field cron expression in an IANA timezone.
Event	Work should react to a platform or custom message, optionally filtered by payload.
Event history	You need the durable record of one event and its target fan-out.
Webhook	RevoEngine should deliver an outbound HTTP request asynchronously.

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.

Job Templates can inherit the instance Job policy, select the invoking caller, or select a saved Service Account. Caller execution requires a known authenticated initiator; unattended Schedules and Events need a Service Account. In Job code, api.currentUser() is the executor; history records the initiator separately. The execution principal is evaluated when the job runs. Use a service account for unattended work and grant it only the platform and resource access the Component needs.

A template owned by an administrator does not cause its jobs to inherit unlimited access. The configured execution principal must remain active and authorized at runtime.

Inputs and history

Template Runtime input is a JSON object stored under options.input and read through api.input('templateInputs'). Each run may also carry its own structured Job input. New integrations should not send JSON encoded as a string. For Job targets, Events and Schedules expose Options → Runtime input with Override (default) and Replace. Override shallowly overlays the automation object onto Job defaults, with automation keys winning. Replace uses only the automation object; {} clears the defaults for that execution. Existing definitions retain their effective input after migration. The input does not change the template’s execution policy, concurrency, or retries. Use several Schedules or Events with one Job template when only input differs, such as weekday partial exports and weekend full exports. See Schedule Runtime input and Event Runtime input for UI steps, examples, and accepted-execution behavior. Use hideRequest 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:

{
  "key": "nightly_sync",
  "limit": 3,
  "ttl": 120
}

key identifies the shared bucket.
limit bounds simultaneous executions in that bucket.
ttl bounds the slot lease if an execution stops reporting progress.

Choose a key based on the resource being protected, not only the template name. For example, all writers to one external account can share a bucket across several templates.

Retry policy

Automatic job retry applies only after a job reaches terminal ERROR. 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.

Cancellation, success, expiration, and handled operator stops do not create automatic retry children. Infrastructure delivery retries are separate from application-level job retry.

Retry only Components whose external effects are idempotent. Store an idempotency key before calling a payment, messaging, or provisioning API.

Job failure notifications

Open Settings → Preferences → Job failure notifications to choose notifications for your account in the current instance. This section requires INSTANCE_ADMIN or AUTOMATION_ADMIN; it does not subscribe other administrators automatically.

Enable System messages, Email, or both. Both channels are off by default.
Choose how Intermediate attempts should be delivered.
Save the preferences.

Intermediate attempts	Delivery when a channel is enabled
Final failure only	Skip failed attempts that already have a retry child; notify on final failure.
Group for 15 minutes	Group intermediate failures into a delayed digest; notify on final failure immediately.
Every failed attempt	Queue each failed attempt immediately, including the final failure.

Grouping is the default attempt preference, but it sends nothing until a channel is enabled. Immediate delivery means queued without the digest delay, not a guaranteed arrival time. Delivery retries do not rerun the Job or change its result. A system message links to the relevant Job. Open it to inspect the attempt, error, processing time and retry lineage before running it again. Email contains a bounded failure summary without copying Job inputs. After an interrupted worker, processing time may be labeled as an estimate based on its last observed activity; missing timing is shown as not measured. Recipients must remain active human accounts with platform access and a qualifying administrator role. Turning a channel off suppresses its queued notifications when eligibility is checked again.

Job lifecycle

SCHEDULED -> PENDING -> PROCESSING -> FINISHED
                         |          ERROR -> retry child
                         +--------> CANCELLED
                         +--------> EXPIRED

Open Jobs → Job History to inspect status, origin, input/output visibility, Component version, processing time, logs, and retry lineage. Immediate Jobs start at PENDING; delayed Jobs start at SCHEDULED. scheduledFor records the accepted dispatch time, not an execution-duration limit. Wait reasons distinguish the scheduled time, dispatch, concurrency, and retry backoff. A due Job can remain pending while another execution holds its concurrency slot. Reading a due Job as PENDING does not itself change its record version. Operator actions have deliberately different meaning:

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.

30 9 * * MON-FRI
Europe/Warsaw

Use a canonical timezone such as 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 a CUSTOM_* 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:

{
  "and": [
    { "field": "message.mimeType", "op": "eq", "value": "text/csv" },
    { "field": "message.metadata.pipeline", "op": "eq", "value": "settlements" }
  ]
}

The equivalent UI property values are 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.

A production ingestion chain is Storage upload → lifecycle Event → filtered Job template → bounded processing → Storage output. Keep Event History ID, Job operation ID, input entry/version, and output entry ID together for replay-safe evidence.

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.

Large messages are omitted from list projections to keep the grid responsive. Open the detail view to load the complete message when authorized. Replay resumes the selected historical event through its current target definitions. It is not a time machine for external systems: Components must still be safe under repeated delivery.

Outbound webhooks

Webhooks send an asynchronous HTTP request with a method, URL, optional headers, and optional body. You can configure additional retries with maxRetries (0 disables retries; -1 permits retries while delivery remains retained), request-detail retention, masked fields, metadata, and a static outbound network path when your integration requires allowlisting. Use maskDetails 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

template / schedule / event / webhook definition
  -> durable request or history record
  -> authenticated background dispatch
  -> current definition and principal revalidated
  -> execution claimed once per attempt
  -> result, logs, and lifecycle persisted
  -> realtime update sent to connected operators

Delivery systems may repeat a request. Durable identifiers, state transitions, and target-specific idempotency prevent a repeated delivery from becoming an uncontrolled duplicate. Your Component remains responsible for idempotency at external side-effect boundaries.

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.

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.

Application interfaces

Data

Files

Collaboration and realtime

Observability

Identity and security

Automation

Job templates

Schedules and events

History

Choose the right primitive

Create a Job template

Inputs and history

Concurrency

Retry policy

Job failure notifications

Job lifecycle

Schedules

Events

Event history and replay

Outbound webhooks

High-level execution flow

Production checklist

Events

Storage

Event History

Schedules

Outbound webhooks

Components

Agents

Observability

Secrets

Job templates

Schedules and events

History

​Choose the right primitive

​Create a Job template

​Inputs and history

​Concurrency

​Retry policy

​Job failure notifications

​Job lifecycle

​Schedules

​Events

​Event history and replay

​Outbound webhooks

​High-level execution flow

​Production checklist

​Related guides

Events

Storage

Event History

Schedules

Outbound webhooks

Components

Agents

Observability

Secrets

Choose the right primitive

Create a Job template

Inputs and history

Concurrency

Retry policy

Job failure notifications

Job lifecycle

Schedules

Events

Event history and replay

Outbound webhooks

High-level execution flow

Production checklist

Related guides