Self-service
Let teams request what they need, without turning every request into a ticket.
Nexus Foundry publishes a catalog of infrastructure, access and data that teams can request directly. Requests within policy provision automatically; requests outside policy route to an approver. Every request becomes part of the audit record, whichever path it takes.
- of requestable items, described plainly
- Catalogof requestable items, described plainly
- when a request is within policy
- Auto-provisionedwhen a request is within policy
- to an approver when it is not
- Escalatedto an approver when it is not
- as part of the audit trail
- Recordedas part of the audit trail
The buyer problem
Requesting access or infrastructure means opening a ticket and waiting.
A developer needs a new database instance. An analyst needs read access to a dataset. Each of these is a routine request that ends up in the same ticket queue as a genuinely complex change, waiting on the same team, judged against no clear policy other than whoever picks it up next.
The bottleneck is not the underlying provisioning step, which is often a single API call. It is the absence of a policy layer that can decide, automatically, when a request needs a human at all.
What changes
A catalog and a policy layer replace a ticket queue.
- Requester
Browse the catalog
A requester picks a published item, a database, a cloud environment, an access grant, from a catalog described in terms they understand.
- Policy
Request is checked against policy
The request is evaluated against eligibility, budget and approval policy before anything is provisioned.
- Provisioning
Automatic where policy allows
Requests that pass policy provision automatically through the underlying workflow, without a ticket sitting in a queue.
- Approval
Human review where policy requires it
Requests that need sign-off route to the accountable approver, with the request context attached.
- Audit
Every request becomes a record
What was requested, by whom, under what policy, and what was provisioned is retained as part of the platform audit record.
Governance does not change as teams move up the ladder. The same workspace permissions, vault-backed secrets, execution history and audit record apply to a visual step and to a code node.
How it works mechanically
Request, evaluate, provision or route, capture.
- 01
Request
A team member requests a catalog item through Foundry, describing what they need in the terms the catalog exposes.
- 02
Evaluate
The request is checked against eligibility and policy: role, budget, environment and any prerequisite conditions.
- 03
Provision or route
Requests within policy provision automatically; requests outside policy route to a named approver.
- 04
Capture
The outcome, whether auto-provisioned or approved, is captured in the audit record alongside the underlying workflow execution.
The loop runs the same way whether the request auto-provisions or waits for an approver; only the routing differs.
Worked example
A developer requests a staging database and an analyst requests dataset access.
Illustrative Foundry request log
Representative output, not a live customer instance
- Request: staging Postgres instanceWithin budget and role policyAuto-provisioned
- Request: read access to customer datasetOutside standard role policyRouted to data owner
- Request: production database resizeRequires change approval by policyRouted to infrastructure lead
- Request: personal sandbox environmentWithin default entitlementAuto-provisioned
Every row, whether auto-provisioned or routed, is retained in the audit record with the request, requester and policy applied.
What you get
Fewer tickets, and a clean record of every request.
A published catalog
A catalog of infrastructure, access and data items, described in terms a requester understands, without needing to know the underlying workflow that fulfils it.
Policy-driven routing
Eligibility, budget and approval policy determine automatically whether a request provisions immediately or waits for a named approver.
One audit record
Every request, whichever path it takes, is captured alongside the workflow execution that fulfilled it, available for later review.
Where it deploys
Part of the platform you already run.
Architecture session
Turn your request backlog into a governed catalog.
We will help you identify which requests can auto-provision safely and which still need a named approver, and set up the catalog to match.