Access Requests
Request, review, approve, reject, and cancel resource access in your Devpilot workspace.
Access Requests
Not every Devpilot workspace member has access to every server, project, or app — and that is by design. When a member needs access they do not currently have, they can submit an access request. Owners and Admins review the request and approve or reject it. This page explains how the flow works for both requesters and reviewers.
Access requests are for existing workspace members asking for access to a specific resource. To add a brand-new person to the workspace, use an invitation instead.
Request Lifecycle
Every request has exactly one status at any time, drawn from this fixed set:
| Status | Meaning |
|---|---|
| pending | Submitted and waiting for a reviewer. The default state immediately after creation. |
| approved | Accepted by an Owner or Admin. If a specific resource was named, the requester is granted the requested role automatically — no separate grant step is needed. |
| rejected | Declined by an Owner or Admin, optionally with review notes that the requester will see. |
| cancelled | Withdrawn by the requester before a reviewer acted on it. |
Once a request leaves pending it is final. A reviewer cannot flip a rejection back to an approval, and a requester cannot cancel a decision that has already been made. If circumstances change, submit a new request.
Each request stores the requester, the resource they named, the role they want, the reason they gave, the reviewer (once one acts), the review notes, the review time, and the full created/updated timestamps. All of this is also recorded in the access audit trail.
Fields on a Request
When you are looking at a request — either as a requester or a reviewer — these are the fields you will see:
| Field | Description |
|---|---|
| Resource type | workspace, server, project, app, or artifact. |
| Resource | The specific resource by id (optional — a request can name a resource type without a specific id, for example "any project"). |
| Requested role | One of admin, collaborator, or viewer. |
| Reason | Free-text explanation, up to 1000 characters. Optional but strongly recommended. |
| Status | pending, approved, rejected, or cancelled. |
| Requester | The member and their linked user account. |
| Reviewer | Populated once an Owner or Admin approves or rejects. Empty on pending and cancelled requests. |
| Review notes | Reviewer's comment on the decision. Visible to the requester. |
| Timestamps | When the request was created, last updated, and reviewed. |
Submitting a Request
Any active workspace member can submit an access request.
Open the Resource You Need
Navigate to the server, project, app, or other resource you need access to. If the resource is hidden because you have no access, open Team > Request Access and select the resource from there.
Click "Request Access"
Open the request form.
Choose the Role You Need
Pick the resource-level role that matches what you need to do:
- viewer — read-only. See the resource but make no changes.
- collaborator — work with the resource (deploy apps, edit project details, create artifacts) without destructive powers.
- admin — full control over the resource, including delete.
Request the minimum role that lets you do your job. Lower-privilege requests are approved faster.
Add a Reason (Optional)
Attach a short reason (up to 1000 characters) explaining why you need the access. A one-line "needed to ship the migration this week" is often enough to unblock an approval.
Submit
The request is created with status pending. Owners and Admins are notified.
Reviewing Requests (Owners and Admins)
Owners and Admins see every pending request for the workspace.
Open Team and Then Access Requests
From the workspace Team area, open the Access Requests tab. By default the list shows pending requests; filter by status, member, resource type, or resource id if you need to.
Review the Details
Each row shows the requester, the resource they named, the role they want, their reason, and when they submitted it. Sort by newest first, or filter to just pending items when running a review queue.
Approve or Reject
Click Approve. You may add review notes. If the request named a specific resource (resource id present), Devpilot immediately creates a WorkspaceAccess grant for the requester at the requested role — no separate grant step is needed. The audit trail captures both the approved event and the paired granted event.
If the request named a resource type but no specific resource id, approval records the decision but does not create any grant — the reviewer should follow up by granting the specific access manually.
Click Reject. Review notes are optional but recommended — the requester will see them and understand what to do next. Rejection closes the request and does not touch any existing access.
Only pending requests can be approved or rejected. Attempting to act on an already-decided request returns an error and does not change its state.
Cancelling Your Own Request
Requesters can withdraw a pending request at any time.
Find Your Request
Open Team > Access Requests and filter to your own pending requests.
Click "Cancel"
The status flips to cancelled. You can submit a new request later if needed.
You can only cancel requests you personally submitted. Owners and Admins cannot cancel someone else's request on their behalf — they can only reject it. Attempting to cancel a request owned by another user is blocked with an access-denied error.
Filtering the Request List
Both reviewers and requesters can filter the list to find what they need:
| Filter | Accepted values |
|---|---|
| Status | pending, approved, rejected, cancelled. |
| Member | Any workspace member id. |
| Resource type | workspace, server, project, app, artifact. |
| Resource | A specific resource id of the chosen type. |
| Per page | 1 to 100 items per page (default 15). |
Results are ordered newest first.
Tracking Requests in the Audit Trail
Every request action — create, approve, reject — is recorded in the access audit trail alongside the requester, the reviewer (when applicable), the resource, and the requested role. When an approval leads to a grant, the audit trail also records the resulting granted event. This gives you a complete paper trail of how a member obtained a specific permission.
Cancellations are reflected on the request record itself (status transitions to cancelled). They are an intentionally low-noise action because no access was granted.
Tips for Smooth Approvals
- Ask for the smallest role that works.
viewerorcollaboratorrequests are approved faster thanadminrequests. - Write a clear reason. One sentence that ties the request to a concrete piece of work is usually enough.
- Request one resource at a time. It is easier to review a narrow request than a sweeping one.
- Watch for notifications. When your request is decided, you will see the outcome and any review notes from the reviewer.
- Re-request rather than re-open. If your situation changes after a rejection or cancellation, submit a new request — the decision on the previous one stays in the record.
Next steps
Access audit trail
See the full history of requests, approvals, rejections, grants, and revokes.
Roles and permissions
Understand the roles you can request and how they map to real actions.
Team management
Manage the members who submit and review access requests.
Invitations
Bring a brand-new person into the workspace instead of using an access request.