Skip to main content
An action definition describes a kind of work your platform performs. An action record is one accepted unit of that work. For example, orders.created can be a definition. The order placed by one customer is a record under that definition. The definition supplies the contract and flow; the record carries the payload, tags, current state, and delivery history.

​
Action definitions

A definition brings together the parts of Arklow that apply to one kind of work:
  • The name work arrives under.
  • The schema used to validate its payload.
  • The sources that create records for it.
  • The rules that tag, transform, route, skip, or terminate its records.
  • The destinations where admitted work can be delivered.
  • The metric policies associated with the work.
Definitions are reusable. You configure the flow once, then each accepted record enters under that definition’s current contract.

​
Variant

The variant is the definition’s canonical name. Use dot notation to describe the domain and event or operation:
The variant is used by HTTP ingress, queue sources, rules, and SDK listeners. Treat it as a stable contract with callers.

​
Schema

A definition can carry a JSON Schema for its payload. Arklow validates incoming payloads before accepting the work. An empty schema accepts any JSON payload. Schema validation belongs at the boundary: invalid work is rejected before it enters the action lifecycle or reaches a destination.

​
Aliases

Aliases record other names associated with a definition. They help keep related identifiers visible during maintenance or a naming migration. The variant remains canonical. Callers should continue to ingest work under the variant unless their integration is deliberately moved to another definition.

​
Version

Definitions begin at version 1, and an update advances the version by one. When ingress omits the version, Arklow uses the current version for that variant. A caller can include the version to assert which current contract it expects. Advance the version when the definition’s contract changes. Keep the variant stable while the work still means the same thing.

​
Flow configuration

The definition’s Flow links its destinations and rules. Rules can add tags, change the payload, select a destination, skip the current dispatch, or terminate the action. Arklow uses the definition’s default destination when no rule selects one. The selected destination resolves the action’s lane from the final tags using its complete-tag or partition-tag identity mode.

​
Action records and runs

Each accepted unit of work receives its own action ID. In the dashboard, these records appear as runs under the definition. The record keeps the payload and tags supplied at ingress, plus the destination and attempt history that develop as it moves through the flow. The definition remains the reusable contract; the run shows the state of one accepted unit.

​
Lifecycle

An action moves through a small set of public states. Delivery guarantees defines attempts, settlement, and redelivery for these states.

​
Create a definition

1

Name the work

Create an action in the dashboard and enter a stable variant such as orders.created.
2

Set the payload contract

Add a JSON Schema, or leave the schema empty when any JSON payload is valid.
3

Link a destination

Open the action’s Flow and link the destination that should receive the work. Set the fallback destination as default when the flow has more than one.
4

Add routing where needed

Add rules when payloads or tags should choose a different destination or control lane.

Quickstart

Create an action and deliver its first record.

Admission control

See why an action waits before delivery.

Sources

Choose where action records enter Arklow.

Destinations

Choose where admitted work is delivered.