Capacity around your operation
Agree admin, channel, product, AI, and MCP allowances around the work your organization needs.
Control the change.
Understand the outcome.
Run content, commerce, and business workflows with clear access boundaries, reviewable AI changes, and a record of why each action happened.
Your frontend. Your business rules. One connected operational foundation.
Access. Review. Execute.
A history behind the outcome.
Bring the controls together around a real business operation: administrator sign-in, permissions, assistant approvals, decisions, record changes, and external delivery.
Your organization’s sign-in.
Your platform’s permissions.
Connect administrator sign-in to your organization’s identity provider. Once the person is authenticated, Ominity permissions determine the operations they can perform. Keep sign-in and authorization clear as your team grows.
- Admin SSO is included from Scale, including Enterprise
- Use admin roles to define the permitted operations
- Keep authentication distinct from customer membership context
Organization identity providerAdministrator sign-in
AuthenticatedJamie SmithAdmin role · Catalog manager
OperationRole decision
Update product informationAllowed
Manage admin accessNot permitted
SSO identifies the person.
Permissions authorize the operation.
Who is acting?
For which business?
Administrator permissions and customer membership context have different roles. Keep access tied to the operation and make the intended context explicit before allowing business work to proceed.
- Resolve the actor behind the request
- Keep customer membership scope deliberate
- Inspect access decisions in the execution context
Useful AI.
A decision your team makes.
Use the assistant’s approval workflow to review proposed writes before they execute. Inspect the requested changes, approve the work that fits your intention, or deny a proposal before it changes your records.
- See the proposed writes as a reviewable list
- Approve or deny before the supported changes run
- Connect approved work to its execution history
Create a landing page for the spring workshops and add the event teaser for the Home barista workshop.
I will create the page from the Default layout, then insert the Event teaser blueprint. Both steps change content, so I need your approval first.
cms_create_pageWRITEname: Spring workshops, layout: Default
cms_add_page_componentWRITEblueprint: Event teaser, position: 1
2 proposed changes
Ask about Ominity…
AutoAsk before changes
Every operation.
A timeline with its reasons.
The execution pipeline brings the request, decisions, and resulting changes together. Follow what was created, updated, or deleted and connect those effects to the action that caused them.
- Identify the actor and business context
- Inspect permissions, rules, and rejection reasons
- Follow the resulting record changes
execution / example-042- 01RequestUpdate a product
Actor and customer context
- 02DecisionAllowed to proceed
Permissions and rules evaluated
- 03ChangeProduct updated
Recorded outcome
- 04OutboxExternal work queued
Delivery has a separate state
Inspect the action through its outcome.
Repeat the request.
Keep the intended effect singular.
Repeatability makes an operation possible to inspect and run again deliberately. Idempotency handles the separate concern of a repeated request producing the same intended effect without duplicating it.
- Connect a repeat to its original intended operation
- Distinguish retries from a new business instruction
- Inspect the recorded effect before proceeding
Example idempotency key
product-update / example-042Requests1
Intended effects1
The original action has one recorded effect.
A repeated request with this key refers to the same intended operation.
Internal work is one state.
External delivery is another.
Outboxes keep external work connected to the execution that caused it. Inspect the queued work and delivery attempts so a successful internal action does not hide an external integration that still needs attention.
- Link external work to its originating action
- Inspect delivery attempts and their outcomes
- Retry delivery within the recorded context
Internal action completedThe business change is recorded
Linked outbox work
Deliver to external serviceQueued
AttemptOutcomeContext
1Delivery not completedOriginal execution
Internal completion does not mean external delivery has finished.
A rule should explain
why the operation qualifies.
Use understandable criteria around the business action. The timeline can expose where the operation was rejected, giving the next person a reason to inspect rather than an ambiguous failure message.
- Express the business criteria explicitly
- Inspect the matched or rejected decision
- Keep the decision connected to its action
Required business contextA customer must be selected
Authorized operationThe actor must have access
Allowed to proceed
Both criteria match this example request.
The right module
owns the right operation.
Use custom fields for domain data and self-contained extensions for specialized capabilities. Apply actions and permissions where work happens, so custom behavior participates in the same operational model.
- Choose typed data for the business domain
- Keep specialized capabilities in a clear module
- Connect custom operations to execution and outboxes
Business recordExample field: external reference
ConfigurationValuePurpose
TypeTextTyped value
includeInResponsetrueAvailable to the frontend
updatablefalseKeep the recorded reference
writeOncetrueSet a value once
filterableStrictExact-value filter
A plan around
your operation.
Enterprise builds on Scale, with allowances, support, and onboarding tailored to your project. Admin SSO is included in Scale and Enterprise.
A deliberate integration plan
Discuss your frontend, identity provider, external services, and custom capabilities together.
Support for the rollout
Shape support and onboarding around your team, implementation, and operational responsibilities.
The plan covers your Ominity license and the hosting of your instance, or a self-hosted, on-premise setup when your organization requires it. Scope frontend development, implementation, and third-party services as part of the complete project.
Clear expectations.
A useful starting point.
Start the conversation with the workflow, the people involved, and the systems it needs to connect.
When should we choose Enterprise over Scale?
Choose Scale when its published allowances and support fit your project. Discuss Enterprise when you need tailored capacity, onboarding, support, or project-specific integration requirements.
Does SSO replace admin permissions?
SSO handles administrator sign-in. Permissions still determine which records and actions an administrator may access.
Does every action require manual approval?
The assistant’s approval workflow lets you review its proposed writes before they execute. Other actions follow the permissions, rules, and workflow you configure for the supported capability.
What should we bring to the first conversation?
Bring a representative workflow, expected team and channel needs, identity-provider requirements, external integrations, and how you want to run and support the project.
Explore the details.
The capabilities, examples, and integration choices behind this solution.
Bring your requirements.
Shape the rollout together.
Discuss your team, identity provider, workflows, integrations, and support needs. Build an Enterprise plan around the complete operation.