Automation needs receipts

Give the operator a place to start

When a follow-up fails or an approval waits, the operator needs to know which customer action needs attention and what already happened.

Currivo's lightweight automation execution data includes an event identifier, status, action-step results, errors and timestamps. Durable workflows additionally keep published definitions by version and record step attempts, waits and approval decisions. An in-flight workflow retains the definition version it started with.

Use the history the particular tool provides. The broader review checklist below includes aspirations such as a complete condition-input snapshot; it is not a promise that every field exists for every Currivo automation.

• The event that triggered the run.
• The version of the rule that evaluated it.
• The conditions that passed or failed.
• Each attempted action and its result.
• A correlation identifier for related logs and events.

Fail visibly

A retry queue is necessary, but it is not an operating interface. Teams need to know when a customer-facing action is delayed, exhausted or awaiting a provider. Preserve the intent and the evidence needed to choose the next step. Before retrying, check whether the provider already received the action. A retry control alone does not guarantee that an external effect cannot repeat.

Keep authority on the server

Hidden buttons do not create authorization. Every automated action should resolve the active workspace and actor on the server, enforce the same permissions as a manual action, and reject ambiguous or cross-workspace identifiers.

Let people override with context

An override should be deliberate, attributable, and recorded. The point is not to make automation impossible to interrupt. The point is to make exceptions understandable after the urgent moment has passed.