owlie
Sign Up Free

Access requests

Request flows users actually complete.

Custom intake Forms per Resource. Approval routing with context, including Function-backed policy decisions. Staged chains with multi-approver quorum — ALL, ANY, or N-of-M. Manager fallback. Reassignment. Cancellation. A clean end-user dashboard to track and approve. Every step evidenced.

Request Early AccessWatch walkthrough

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.

  1. 01

    Submission.

    An admin creates the request against a Resource and fills its custom Form — text, pickers, or governed file-upload fields. Self-service end-user submission, with a catalog scoped to what each person can request, is on the way.

  2. 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.

  3. 03

    Approval.

    Approver sees the request with context — who, what, why, what policy applied, who else is in the chain. Approves, rejects, or reassigns.

  4. 04

    Fulfillment.

    On final approval, the request hands off to provisioning. Automated connector, manual ticket, Function, or virtual — same pipeline.

  5. 05

    Evidence.

    The request settles with a full trail: submission, approval chain, fulfillment steps, outcome. Auditable as one 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.

A stage advances only once its quorum is met — one approver, everyone, or N-of-M, with multiple approvers acting in parallel inside the same stage. By default, a rejection stops the chain the moment it makes that quorum unreachable — immediate for a single-approver or all-must-approve stage — though an N-of-M stage can be set to fail on the first rejection instead. Manager-based stages fall back to a named user or group when the beneficiary has no manager record. Policy-driven stages can reassign dynamically, and a reassignment keeps the current stage open under the new assignee rather than advancing the chain. Later stages wait until the current stage resolves.

Notifications

Every status change reaches the right person — once.

Request and approval notifications don't ride ad-hoc emails scattered across services. They move through one governed pipeline: a typed catalog — request submitted, approved, denied, fulfilled, canceled; ticket assigned — resolved against per-tenant channel policy and each person's own preferences, over email and in-app. Every delivery is tracked per recipient and channel, retried on a backoff, and dead-lettered if it never lands rather than silently dropped. Repeated emissions of the same event collapse to a single message, and a failed notification never changes the state of the request that triggered it.

Keep going.

Platform overview

Runtime, primitives, pipeline — how the pieces fit.

Provisioning

Intent-based, versioned provisioning with connector, manual, Function, and virtual paths.

Extensibility

Functions, Forms, Hooks — the primitives behind every request flow.

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.

Request Early AccessWatch walkthrough