The scope behind the story.
OneAdmin’s central control model is human approval or prior policy assignment before execution, with every agent request visible to its responsible administrator. This guide separates that contract from current implementation scope.
The admin inbox is the decision boundary.
Every proposed administrative action should identify its initiator, target, responsible administrator, and impact. Agent initiation creates a request; it does not authorize execution.
- Human approval: the responsible administrator reviews and approves the exact proposal within their authorized scope.
- Prior assigned policy: an authorized administrator has already assigned an active policy covering the agent, operation, target, environment, and risk. Its identity and version belong in the record.
- Neither applies: execution remains held. An expired or mismatched policy is not authorization.
- Every outcome stays visible: approvals, policy decisions, blocked attempts, rejections, execution results, and verification receipts remain attached to the request.
The homepage inbox is an interactive demonstration of this intended model. Admin routing, approvals, policy-gated execution, and receipts use synthetic local state; no real request is approved or executed.
Current code includes request intake, delegation preflight, validation/rejection surfaces, and activity records. Unified action dispatch remains unimplemented. Power BI has a separate publishing path. These existing paths must be brought behind the common execution gate before this contract can be claimed as universally enforced.
Start with supported assets.
Power BI focuses on admitted models and workspaces. Oracle EPBCS starts with uploaded application snapshots. The scope below describes implementation, not general availability or complete tenant coverage.
| Capability | Power BI | Oracle EPBCS |
|---|---|---|
| Inventory & inspection | Admitted models and workspaces | Uploaded application snapshots |
| Dependency context | Measure-to-column dependencies | Parsed application artifacts |
| Change preparation | Selected manual request workflows | Snapshot-based investigation |
| Live platform actions | Dedicated publishing workflow | Planned |
| Cross-system lineage | Planned | Planned |
| Unified approve & execute | Planned | Planned |
Explore an illustrative admin workspace
Your operational inventory
4 assets| ASSET | PLATFORM | CONTEXT |
|---|---|---|
| Oracle EPBCS | Snapshot | |
| Power BI | Model | |
| Power BI | Measure | |
| Power BI | Planned |
A shared view of the asset, its dependencies, and the work around it.
Lineage, with its evidence attached.
Current Power BI dependency code connects measures to the columns they use inside a workspace. That is a concrete starting point for understanding a model.
The roadmap adds tenant inventory, asset-to-asset dependencies, and verified connections between systems. The intended experience brings ownership, access, and recorded changes alongside those dependencies.
- Model context: inspect supported measure-to-column relationships.
- Asset lineage — planned: follow sources, models, reports, and downstream consumers.
- Cross-system impact — planned: connect verified relationships across supported systems and assess the scope of a proposed change.
The interactive illustrations on this site show this direction. Their sample assets, owners, and relationships are not connected customer data.
Preparation and execution have different scopes.
Selected Power BI manual requests can carry context into a workspace for preparation. Some requests need an administrator to open the workspace and initiate the agent workflow; automatic preparation is not universal.
Power BI has a dedicated publishing path. Unified cross-platform approval and execution are planned capabilities. Preparing or validating a request does not mean a change has been executed in the target platform.
Working with existing request processes.
OneAdmin includes generic request intake and external request references. Dedicated provider parsing and end-to-end fulfillment for ServiceNow, Jira, and Slack require additional integration work. A generic webhook does not establish a complete provider integration.
What activity records cover.
OneAdmin activity records can include the actor, platform, request, and delegation. They represent activity recorded by OneAdmin. They should not be interpreted as a complete history of changes made directly in every connected platform.