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

Schemas are optional. When you use them, you can ensure that work entering Arklow matches the required shape, or it is thrown away. We recommend that you rely upon existing schema checks in your pipeline, using this feature only for added protection.

​
Aliases

Aliases can be used to temporarily associated new variant identifiers with the current action. Often this can be useful for migrations, or moving old work to new actions.
Aliases are meant to be used for migration, or for maintenance reasons. They will take priority over existing Action Variant names. This can cause unintended effects, or deliver work to the work Action.

​
Version

Definitions begin at version 1. When incoming work omits the version, Arklow uses the current version for that variant. A caller can include the version to assert which current contract it expects. If a version, for whatever reasons becomes invalid, or unavailable, Arklow will use the latest version.

​
Flow configuration

Flow is a UI-only feature that visualizes the entire Action, and all how work moves through it. We recommend that you use it initially to configure your first actions, before moving to API/Terraform based configurations.

​
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.