Access requests
Request flows users actually complete.
A clean end-user dashboard. Custom intake forms per Resource. Approval routing with context, including Function-backed policy decisions. Sequenced approval chains. Manager fallback. Reassignment. Cancellation. Every step evidenced.
Request detail — approval chain in context
Hero-width admin view of a request: beneficiary, Resource, current step, policy, chain position.
Lifecycle
Submission to evidence, in one record.
Every request travels the same five beats. Each beat has a concrete surface — an end-user screen, an approval card, a fulfillment handoff, a journal entry — and each beat writes to the same request record.
-
01
Submission.
User picks a Resource from a catalog scoped to what they can actually request. Fills the custom Form if the Resource has one. Submits.
LC-04asset pendingRequest catalog + custom Form
End-user view: Resource catalog scoped to the requester, with a custom Form for the selected Resource.
-
02
Routing.
Owlie resolves the approval path from the Resource's configured policy — a specific user, a group, the beneficiary's manager (with configurable fallback), or a Function that decides dynamically.
LC-04asset pendingRouting resolution
Policy resolution: named user · group · manager (+ fallback) · Function.
-
03
Approval.
Approver sees the request with context — who, what, why, what policy applied, who else is in the chain. Approves, rejects, or reassigns.
LC-04asset pendingApproval card — request in context
Approver view: beneficiary, Resource, policy applied, chain position, actions.
-
04
Fulfillment.
On final approval, the request hands off to provisioning. Automated connector, manual ticket, Function, or virtual — same pipeline.
LC-04asset pendingFulfillment handoff
Approved request entering the provisioning pipeline: connector / manual / Function / virtual path.
-
05
Evidence.
The request settles with a full trail: submission, approval chain, fulfillment steps, outcome. Auditable as one record.
LC-04asset pendingRequest record — full lifecycle trail
Settled request: submission, routing, approvals, fulfillment, outcome — one auditable record.
Approval patterns
The decision models your policy actually uses.
Each Resource carries its own approval policy. The policy picks the pattern — not the other way around.
- Named approver
- Single user owns the decision.
- Group approval
- Any member of a group can approve. First response wins.
- Manager approval
- Routes to the beneficiary's manager, with configurable fallback when the manager record is missing or invalid.
- Policy-driven
- A Function decides: auto-approve, auto-reject, or hand the decision to a specific user or group based on the request's shape.
Chains
Multi-step approval that doesn't restart on a snag.
Chains advance only after the current step approves or reassigns. Rejection at any step stops the chain immediately. Manager-based steps can fall back to a named user or group when the beneficiary has no manager record. Policy-driven steps can reassign dynamically, keeping the request moving without forcing a restart. Approval progression is step-ordered per Resource; parallel-within-a-step is not supported at launch.
Request flows shaped to your policy — not to a vendor's form.
Early access is open. Start with the approval paths your business already runs.