One execution pipeline.
Creates, updates, deletes, and business actions follow a structured path with recorded outcomes.
Every action.
A story you can follow.
Who changed it? Why did it happen? What did it produce? Ominity routes changes and business actions through an execution pipeline, connecting each request to its decisions and outcome.
For teams that need to understand and explain how their platform behaves.
An action with a history
Execution EX-041
CompletedUpdate product price
- Why it startedJamie approved a proposed price change.
- What happenedPermissions and input checked. Product updated.
- What it producedA recorded change and linked external work.
Before€29.00
After€32.00
Context around each action.
Follow the origin, action, decisions, changes, and resulting work as one connected story.
Work you can follow.
Investigate rejections, repeat supported actions, and trace external delivery through outboxes.
Follow the full story.
One event at a time.
Inspect a completed change, a rejection, or a repeated request. Select an event to see the context and evidence behind it.
Execution timeline
01 / 06Recorded
Request received
A proposed price change was approved and entered the execution pipeline.
SourceOminity Assistant
ActorJamie Smith
ActionUpdate product price
RecordProduct EE-001
Requested change
Before€29.00
After€32.00
One execution. Connected evidence.Local change completed · External delivery queued
A decision.
With a reason.
An action that does not run still has a story. See which check rejected the request, why it was rejected, and what happened as a result.
- Separate a request from an applied change.
- Inspect the action’s recorded rejection reason.
- Explain the outcome without reconstructing it from scattered logs.
A decision you can inspect
Execution EX-042
RejectedUpdate product price
Requested price−€5.00
Permission checkActor can update this product.
PassedInput validationPrice must be greater than zero.
RejectedRecorded reasonThe requested price does not meet the action’s validation rule.
Product unchanged No outbox work created
Retry with confidence.
One request. One result.
A repeated request should not become a second product update. Idempotency lets the action recognize the same operation and reuse its result, keeping duplicate effects out of the workflow.
Try another request in this example. The attempt count grows; the product change and outbox message stay at one.
Same request. Same result.
Idempotency key
price-update-ee001-041- 01Original requestApplied · Execution EX-041Completed
- 02Repeated requestOriginal result reused · EX-041Reused
1Product change
1Outbox message
2Request attempts
A repeated request adds no duplicate change.
Repeatable does not mean identical.
Running a supported action again is a separate decision from retrying the same request. A new operation is evaluated in its current context and has its own execution story.
Original actionEX-041Update product price
Input, context, decisions, and result remain in its history.
Run a supported action again
New invocationA new executionCurrent context, fresh decisions
A separate operation passes through the pipeline and records its own outcome.
Beyond your instance.
The trail continues.
External work uses outboxes. Connect a delivery attempt to its message and the action that started it, while keeping the local execution and delivery outcome distinct.
External delivery, with its own history
Local execution
Product price updated
CompletedEX-041Outbox message
External work linked to its origin
DeliveredOB-1042 · product.updatedExternal service
Example inventory integration
ReceivedMessage OB-1042Delivery attemptsLocal execution stays completed.
- 01Request timed outRetry recorded
- 02Service unavailable · 503Retry recorded
- 03Service accepted · 200Delivered
3 delivery attempts, all linked to the same message and execution.
From a record.
To the evidence.
Audit trails connect changes to the actions behind them. Move from what changed to who acted, the request’s origin, the recorded decision, and the resulting timeline.
That context matters when teams investigate an unexpected update, review an AI-assisted action, or explain an operational outcome.
Connect approvals to actionsHistory of product EE-001
Everyday essentialsFrom the record to the actions behind it.
- CreatedProduct EE-001 createdAdmin interface · Jamie Smith
- UpdatedPrice: €29.00 €32.00Assistant approval · Jamie Smith
- RejectedInvalid price. Product unchanged.API request · Integration admin
Useful when the answer
needs evidence.
Enterprise operations
Explain a business action using its context, decisions, and outcome. Give operational teams a shared starting point for investigation.
AI-assisted work
Connect an approved proposal to the actions it produces. Keep the reason for a change beside the evidence of what actually happened.
Connected systems
Follow queued external work, retry attempts, and delivery results. Find the originating execution when an integration needs attention.
A closer
look.
Discuss the actions and external workflows your team needs to trace.
Is a rejected action part of the history?
Yes. A rejection is an outcome worth understanding. The pipeline records the decision and its reason, so you can distinguish a blocked action from a successful change.
How do repeatability and idempotency differ?
Repeatability lets you run supported actions again with a recorded outcome. Idempotency handles repeated requests for the same operation without duplicating its effects. A genuinely new operation has its own execution and current checks.
Why is external work in an outbox?
External delivery has its own lifecycle. The outbox links that work to the originating execution and tracks delivery attempts and their results, so you can follow both the local action and what happened outside the instance.
Build with confidence.
Keep the story.
Bring your content, commerce, AI, and custom business logic onto a foundation your team can investigate and explain.