Idempotency
A property of an operation whereby performing it multiple times has the same effect as performing it once, making retries and replays safe.
In more detail
An operation is idempotent if doing it repeatedly is indistinguishable from doing it once. Setting a status to paid is idempotent; incrementing a balance is not. The property matters because distributed systems retry, and without idempotency a retry after an uncertain failure can double-charge, double-send, or double-create.
Idempotency is usually achieved with a unique key that identifies the intended operation, so the system can recognize a repeat and skip the duplicate effect. Building operations to be idempotent, or wrapping them in idempotency keys, is a prerequisite for safe retry logic in any automation that touches real systems.
Where this shows up at Ceven
Because Ceven workflows take real actions across connected tools, safe retries matter: a step that runs again after an uncertain failure should not create a duplicate. Designing actions to be idempotent is part of what lets Ceven recover from transient errors without doubling an effect, and the audit trail makes any such retry visible rather than mysterious.