Connect an event to an action

Build Niqat workflow integrations around versioned events, allowed domain commands, explicit permissions, and safe retries. Keep business changes reviewable.

A workflow starts from a business event and calls permitted application commands. The event describes what happened; the command is the authorized request for what should happen next.

Define the trigger

The portable workflow content uses a trigger with event_type and schema_version, and an actions array. Each action carries key, command_name, depends_on, and configuration.

The installed deployment owns the event and command allowlists. Use their documented names and versions. This guide does not invent a universal event name or command endpoint.

Keep the graph bounded

Give actions stable keys. Dependencies must be explicit and acyclic. Define an approval boundary where a person must review a change, and avoid hiding mandatory accounting or inventory effects in optional automation.

The interactive workflow illustrates a stock threshold leading to a request and approval. It is a visual example, not an installed workflow definition.

Plan for repeated delivery

Treat event handling as something that may be retried. Keep the event identity and intended command identity stable, and define how an exact retry differs from a changed request.

Do not issue a second payment or duplicate stock effect because a network response was lost. Use the command boundary’s idempotency contract rather than an optimistic UI flag.

Keep integration secrets out of packs

A shared workflow template should not contain provider keys, database credentials, or private company identifiers. Bind credentials at the authorized runtime boundary.

Review before distribution

Document the trigger, reads, changes, approval needs, failure behavior, and compatibility. A recipient should understand what the workflow will do before activating it. Distribution through the Niqat Store is coming soon.