Creating an Intake Workflow for High-Risk Requests
Introduction
High-risk requests require additional controls during intake to ensure they are reviewed and handled according to organizational policy. These requests typically involve elevated permissions, sensitive systems, or actions with limited reversibility.
This article explains how intake workflows for high-risk requests can be configured in Console by identifying risk at request creation and applying defined intake and approval controls prior to execution.
Defining high-risk requests
High-risk requests are those that require stricter review or handling than routine requests.
Common examples include:
Requests for administrative or elevated access
Changes to production or security-sensitive systems
Requests affecting multiple users or shared resources
Actions that cannot be easily rolled back
These requests are typically identified based on internal security, compliance, or operational policies.
Using request types to separate high-risk intake
Console supports creating distinct request types, each with its own configuration. High-risk requests can be assigned a dedicated request type so they enter the system with different controls applied.
A dedicated request type allows teams to:
Apply stricter intake requirements
Limit who can submit the request
Configure approvals and handling independently of routine requests
This separation ensures that high-risk requests do not follow the same intake path as standard requests.
Collecting required context with intake questions
Intake questions are used to collect necessary information at the time a request is submitted. For high-risk requests, these questions ensure reviewers have sufficient context to evaluate the request.
Common intake fields may include:
The system or resource involved
The level or scope of access requested
The business justification
Duration of access, if applicable
Any dependencies or constraints
Console also verifies identity and access context before taking action, including checking whether a user is in the appropriate Okta groups prior to execution. This ensures requests are only fulfilled for users who are authorized, preventing sensitive information or access from being granted to the wrong person.
Applying approvals before execution
Console supports approval steps that must be completed before actions are taken. High-risk request types can require one or more approvals prior to execution.
Approvals:
Are evaluated using the information collected during intake
Block execution until approved
Provide a record of authorization decisions
This ensures sensitive actions are not performed without explicit approval.
Controlling what happens after approval
After approvals are completed, requests can be configured to proceed in different ways depending on the request type and outcome.
High-risk requests can be configured to:
Execute defined actions
Be routed to designated operators or teams
Be closed or returned if approval is denied or additional information is required
This allows organizations to maintain control over how sensitive requests are handled.
Summary
High-risk requests benefit from additional controls during intake. By separating these requests into dedicated request types, collecting structured context upfront, requiring approvals before execution, and controlling post-approval handling, organizations can manage sensitive requests in a consistent and controlled manner.
Console provides the core features needed to configure these workflows without relying on manual follow-ups or ad-hoc handling.