Access Requests

Requests gives employees a structured way to ask for application access and gives authorized reviewers a central place to review the request context. The workflow records the request and its decision; approval does not automatically provision access inside the external application.

​

The Requests page

The page shows requests submitted in your workspace and their current status, such as:

• Pending — waiting for a decision
• Approved — the request was approved
• Denied — the request was denied
• Cancelled — the requester withdrew the request
• Expired — no decision was made within the workspace’s time limit

Pending requests expire automatically after a period your workspace can configure. The information shown depends on your role and workspace permissions.

​

How an employee submits a request

Employees open Requests, choose New Request, and provide the application, business justification, urgency, and any additional context requested by the workspace. The requester receives confirmation through the notification channels enabled for the workspace. Reviewer notifications also depend on workspace configuration.

​

Reviewing requests

Authorized reviewers can inspect the requester, application, justification, available risk context, and related approved applications before recording a decision.

​

Approving

1. Click Approve.
2. Add an optional note for the requester.
3. The request records the approval decision.
4. If your workflow supports it, separately add or update the application record in the Porcia catalog.

Approval is a governance decision. It does not create an account, assign an external license, or change access in the requested application unless a separate, explicitly enabled provisioning workflow exists.

​

Denying

1. Click Deny.
2. Add a clear note for the requester.
3. Optionally suggest an approved alternative.
4. The request records the denial decision and notifies the requester through configured channels.

​

Notifications

Notifications depend on the channels enabled for the workspace. In-app notifications are available where supported; email, Slack, and Teams delivery require their respective configuration and may have different delivery behavior.

​

Request history and auditability

The request keeps its decision history and supported notes or messages. Workspace audit visibility depends on the action and the configured role/access scope; this page should not be interpreted as a guarantee that every related delivery or downstream application action is logged in one audit stream.

​

Rules

Where Rules are enabled, supported request events can be used to notify or route work to the appropriate reviewer. Rules do not automatically grant access in the external application unless a separate approved provisioning workflow is enabled.

​

Next steps