Request Approvals

Overview

In Optima Orbit, employees can order items, ask for access, or submit structured forms through the Service Catalog. Many of these Service Requests — such as ordering a new laptop or requesting access to a restricted database — incur costs or carry security risks.

Request Approvals is the dedicated workspace where authorized personnel (like line managers, department heads, or IT owners) review these requests and authorize them before any actual work begins.

Why Request Approvals Exists

Not all requests can be instantly fulfilled. Request Approvals acts as the organizational gatekeeper to:

• Control Costs: Ensure expensive requests (like hardware or software licenses) have budget approval.
• Enforce Security: Verify that an employee truly needs access to a specific system or building.
• Prevent Wasted Effort: Stop invalid requests before they reach the IT or Facilities teams, keeping the Service Desk clear of unapproved work.
• Maintain an Audit Trail: Permanently record exactly who authorized a sensitive request and why.

Key Concepts: Requester vs Approver vs Fulfiller

To understand this page, it is critical to separate the three roles involved in a Service Request:

Actor	Responsibility	Typical Action
Requester	The person who needs something.	Submits the form via My Service Requests.
Approver	The person deciding if the request is allowed.	Uses Request Approvals to click Approve/Reject.
Fulfiller (Agent)	The team performing the actual work.	Uses Service Desk to fulfil the request after approval.

How to Access Request Approvals

1. Open your Personal Workspace via the main navigation menu.
2. Select Request Approvals (look for the clipboard/inbox icon).

[!NOTE] Request Approvals operates on a strict permission model. You must have the org.servicedesk.requests.approve permission to access this page. Without it, the menu item is hidden.

How the Approval Lifecycle Works

My Service Requests vs Request Approvals

It is easy to confuse these two spaces.

My Service Requests (/org/service-requests/my)	Request Approvals (/org/service-request-approvals)
Requester-focused.	Approver-focused.
Shows requests you submitted.	Shows requests waiting for your decision.
You go here to check if your IT ticket is done.	You go here to authorize work for your team.

Understanding the Request Approvals Screen

The workspace uses a highly efficient split-screen design, allowing you to process dozens of requests without opening new tabs.

The Pending Queue (Left Sidebar)

This list shows all requests waiting for your authorization. Each card displays:

• Request Type: (e.g., "Request Software License") and its unique Catalog Key.
• Requester: The name of the person who submitted it.
• Project: The project this request is billed to or associated with (or "General").
• Submitted Date: When the request was made.
• SLA Progress Bar: A colored bar that shrinks and turns from green to red as the deadline to make a decision approaches.

Toolbar and Filters

If your queue is full, use the top toolbar to organize it:

• Search: Find requests by the requester's name or the request title.
• Group By: Group the list by Project, Requestor, or Request Type.
• Project Filter: Show only requests belonging to a specific project.
• Tabs: Switch between Pending My Approval (action required from you) and My Requests (where your own approvals are stuck).

Reviewing a Request (Detail View)

Clicking a request in the left queue loads its full details in the right panel.

1. Request Details (Form Answers)

This is the most critical section for an approver. It displays the exact answers the requester provided when filling out the Service Catalog form.

Because every catalog item is dynamically customized by administrators, you might see fields like:

• Software Name
• Business Justification
• Required Date
• Cost Center

[!IMPORTANT] No Attachments View: Unlike Expense Approvals, the Service Request Approvals page focuses purely on structured form data. If the catalog item required file uploads, those are passed directly to the fulfilment agents in the Service Desk.

2. Comments History

If this request requires multi-level approvals (e.g., Line Manager first, then IT Security), you will see comments left by previous approvers here.

Before You Approve

Before making a decision, you should mentally check:

1. Is the requester correct? (Do they report to me or belong to my project?)
2. Is the request necessary? (Read the dynamic form variables, specifically the business justification).
3. Is it urgent? (Check the SLA timeline and priority).
4. Has anyone else objected? (Check the Comments History for previous stages).

Making a Decision

At the bottom of the detail view, you will find the action bar. The available actions depend on how the workflow is configured, but generally include:

Approving a Request

1. Select the request.
2. Review the requester's form answers.
3. Click Approve.
4. (Optional) Enter a comment in the text box. Unlike rejections, approval comments are usually optional.
5. Confirm.

What Happens Next? If you are the final approver, a Fulfilment Ticket is instantly created in the Service Desk for the assigned team to begin work, and the Request Status changes to APPROVED. If there are more stages, it moves to the next approver's queue.

Rejecting or Returning a Request

If a request is invalid, too expensive, or lacks detail, you should reject it.

1. Select the request.
2. Click Reject (or Return to ask them to fix it).
3. Mandatory Comment: You must type a reason in the Approval Comment box before the system will accept a negative action.
4. Confirm.

What Happens Next? The workflow halts. No Service Desk ticket is created. The requester is notified via email/app notification that their request was rejected, along with your exact comment explaining why. The Request Status changes to REJECTED.

Why Is This Request Assigned to Me?

Service Requests don't rely on guesswork. They arrive in your queue because of an Approval Workflow configured by your organization's administrators. You were selected because:

• You are mapped as the employee's direct reporting manager in the Team Hierarchy.
• You are the Project Manager for the project selected in the form.
• You hold a specific Role (e.g., "IT Security Approver") that is required for this specific catalog item.

Request Status vs Approval Status

It is helpful to understand how the system tracks these two distinct states:

Type	Status	Meaning
Approval Status	PENDING	The specific step waiting for your decision.
Approval Status	APPROVED	You have successfully authorized your step.
Request Status	PENDING	The overall request is waiting in someone's queue. No work has started.
Request Status	APPROVED	All approvers said yes. A ticket has been created for fulfilment.
Request Status	REJECTED	An approver denied it. The request is dead.

Technical Reference

For administrators and QA engineers, here are the technical implementation details for this module:

• Route: /org/service-request-approvals
• Component: src/routes/org/servicedesk/ServiceRequestApprovalsPage.tsx
• Required Permission: org.servicedesk.requests.approve
• Core API Flow:
  • GET /org/approvals/pending (Fetches queue, filtered strictly by module_code === 'SERVICE_REQUEST')
  • GET /org/service-requests/{id} (Fetches the underlying ServiceRequest to extract variables)
  • GET /org/approvals/{id}/timeline (Fetches historical visual workflow steps)
  • POST /org/approvals/{id}/process (Submits {action, comments})
• Data Models: ServiceRequest (from servicedeskService.ts), ApprovalInstance (from approvalService.ts).
• Validation Logic: Frontend validation strictly blocks REJECT or RETURN actions if comments.trim() is empty. APPROVE actions do not enforce this block.

Related Features

• My Service Requests
• Team Hierarchy
• Approval Workflows (coming soon)

Internal requests waiting on your decision.