Requesting Feature Access¶

This guide explains how to request access to a platform feature your project does not yet have, how that request is reviewed and approved, and how to track it through to Available.

See Permissions Glossary for the canonical definitions of Limit, Grant, Available, and Request.

How access works¶

Every platform feature — managed apps, DNS, object storage, Kubernetes, compute — starts as not Available to a project until your organization's settings are configured and, in most cases, an org admin has approved it.

The chain:

1. b'nerd sets a Limit for your organization — the maximum set of features it may use. If no Limit is set, your organization is unbounded and may use any feature the platform supports.
2. An org admin creates a Grant that distributes specific features to individual projects, within the Limit.
3. The result — Grant ∩ Limit — is what is Available to the project at runtime.

A Request is how you ask your org admin (or b'nerd, for provisioned features) to extend what is Available to your project.

Who can request¶

Any organization member can submit a feature request for a project. Whether it is approved automatically or requires an org admin's action depends on two things:

• Whether you hold the features:request permission for your organization (org admins always hold it; other members can be delegated it — see Delegating request authority below).
• Whether the feature is self-service or provisioned-tier.

Provisioning tiers¶

The request lifecycle¶

Member submits request (POST /projects/{id}/feature_requests)
  │
  ├─ Self-service feature (apps / dns / object_storage)
  │     ├─ Auto-approve enabled (per-feature opt-in by org admin)
  │     │     └─ Approved immediately → AVAILABLE
  │     │
  │     └─ Auto-approve OFF (default — fail-closed)
  │           ├─ You hold features:request
  │           │     └─ Self-authorized → AVAILABLE
  │           └─ You do not hold features:request
  │                 └─ PENDING APPROVAL → Org admin approves or denies
  │                       ├─ Approve → AVAILABLE
  │                       └─ Deny   → DENIED
  │
  └─ Provisioned-tier feature (kubernetes / openstack)
        ├─ You hold features:request
        │     └─ WITH B'NERD → b'nerd provisions → AVAILABLE
        └─ You do not hold features:request
              └─ PENDING APPROVAL → Org admin reviews → forwards to b'nerd
                    ├─ Forward → WITH B'NERD → b'nerd provisions → AVAILABLE
                    └─ Deny   → DENIED

States you will see in the dashboard:

Every row in the Capabilities view shows the live state of your requests so you always know where your request stands.

Submitting a request¶

Dashboard¶

Open your project, go to Capabilities, find the feature you want, and click Request access. The form lets you describe what you need; for provisioned features (Kubernetes, compute), a brief description of your intended use helps b'nerd provision the right configuration.

API¶

POST /projects/{project_id}/feature_requests
Authorization: Bearer <token>
Content-Type: application/json

{
  "feature_key": "kubernetes",
  "configuration": {
    "allowed_kinds": ["Managed::Kubernetes::V1"]
  },
  "request_notes": "Production cluster for the payments service"
}

Response — 201 Created

{
  "metadata": {},
  "data": {
    "id": "pfr_abc123",
    "feature_key": "kubernetes",
    "status": "pending",
    "provisioning_tier": "provisioned"
  }
}

Response fields

Polling for status¶

GET /projects/{project_id}/feature_requests/{id}
Authorization: Bearer <token>

Returns the current request with its status. You can also list all requests for a project:

GET /projects/{project_id}/feature_requests
Authorization: Bearer <token>

Auto-approve: zero-click self-service¶

For self-service features, an org admin can enable auto-approve for a specific feature key. When auto-approve is on, any member's request for that feature within the organization's Limit is approved immediately — no org admin action needed.

Auto-approve is OFF by default (fail-closed). An org admin must explicitly enable it per feature via Organization → Features → [feature] → Auto-approve.

Auto-approve applies only to self-service features (apps, dns, object_storage). Provisioned-tier features (kubernetes, openstack) always require org admin review and then b'nerd provisioning — there is no auto-approve path for them.

Delegating request authority¶

The features:request permission determines whether a member can authorize their own requests (for self-service) or forward a request directly to b'nerd's provisioning queue (for provisioned features) without waiting for an org admin.

• Org admins always hold this permission.
• Other members do not hold it by default.
• An org admin can delegate it to a trusted member via Organization → Members & Roles → [member] → Feature Requests.

When a member who holds features:request submits a request:

• Self-service feature → self-authorized, approved immediately (regardless of auto-approve setting).
• Provisioned feature → forwarded directly to b'nerd's provisioning queue, skipping the Requests inbox.

When a member who does not hold features:request submits a request, it goes to the org admin's Requests inbox for review first.

For org admins: reviewing requests¶

When a member submits a request and auto-approve is OFF, it appears in Organization → Requests.

Self-service requests¶

Approval cannot exceed the org's Limit — the platform enforces this unconditionally. Bulk approve is available for clearing multiple pending requests at once.

Provisioned-tier requests (Kubernetes / Compute)¶

For provisioned features, member requests that need org admin review appear in the inbox. As org admin you can:

Once forwarded, the request shows as with b'nerd in your Requests view — no further action is needed from you unless b'nerd contacts you for configuration details.

Enabling auto-approve for a feature¶

To remove the approval step for a self-service feature:

PATCH /organizations/{id}/features/{feature_key}
Authorization: Bearer <token>
Content-Type: application/json

{ "auto_approve": true }

Or via Organization → Features → [feature] → Auto-approve: on.

Disabling auto-approve takes effect immediately for new requests; requests already approved are unaffected.

Notifications¶

You receive an in-app and email notification when:

• As a requester: your request is approved, denied, or becomes Available.
• As an org admin: a new self-service request arrives (when auto-approve is OFF).
• As an org admin: a new provisioned-tier request arrives requiring your review.

See also¶

• Permissions Glossary — Limit, Grant, Available, Request
• Feature Access & Grants API — the grant API used by org admins
• Roles & RBAC — roles, presets, and permission categories
• Concepts — organization, project, and capability overview