Approve or reject a request

What this achieves

Requests that need a decision from you arrive in one inbox instead of arriving as email. This page covers opening a waiting task, reading what is being asked, and recording the decision.

Required role: Administrator or Manager.

Steps

Go to Approvals → Task Inbox.
Stay on the Pending tab. It lists only tasks still waiting on a decision.
Select a row to open the task.
Read Request Details. This is the request in plain terms — who raised it, who it is about, and the values that matter to the decision.
Enter Comments. A comment is required before you can approve or reject.
Select Approve or Reject.

What the inbox columns tell you

Option	Description
Step	The name of the step you are being asked to complete, as the route names it.
Type	The kind of step. Yours will normally be APPROVAL.
Workflow	The route this task belongs to.
Assignee	Who the task is waiting on.
Status	Where the task is in its own lifecycle.
SLA	Time left against the step’s deadline, or BREACHED if the deadline has passed.
Created	When the task reached the inbox.

Example: Olivia Bennett opens the inbox and sees a training request from James Whitfield with four hours left on its deadline, and a transfer request already showing BREACHED. She takes the breached one first, because it has already escalated.

The All and Completed tabs show the same tasks after a decision has been made, which is where you look to confirm you did act on something.

Your own tasks, on their own screen

Approvals → My Tasks shows only the tasks assigned to you, one card each, with the deadline stated as Overdue, No deadline, or a due time. Each card offers Approve, Reject, and View details.

Use the Task Inbox when you are working through a queue and want the columns. Use My Tasks when you want to see what is on you personally.

You cannot approve your own request

If you raised the request yourself, the approve action is unavailable and the task says so: separation of duties prevents self-approval. Reject stays available, so you can withdraw your own request without needing someone else to do it for you.

Example: Priya Raman raises a request that routes to the Finance approver group, of which she is a member. She can reject it, but not approve it. A second approver — Daniel Okonkwo — has to approve it, which is the point of the control.

This is enforced by the product, not by convention. An approval step cannot be configured to send a request back to the person who raised it.

Rejecting

Rejecting records a decision. It does not edit the request and it does not open it for correction.

What happens after a rejection depends on how the route was drawn:

Option	Description
A step with one outgoing path	The rejection ends the request. Nothing further runs.
A step with separate approved and rejected outcomes	The rejection follows the rejected path, which may notify someone or route the request elsewhere.
A step inside an all-must-approve parallel branch	The rejection halts the branch immediately. The other approvers on that branch are not left waiting.

Example: Olivia Bennett rejects a paid training request because the reason field says nothing. James Whitfield raises it again with a reason. That is a new request, not the old one reopened.

Write the comment for the person who receives it. It is the only explanation they get.

Recording an outcome other than approve or reject

Some steps are drawn with more than two outcomes — for instance approved, rejected, and escalated. Custom Decision submits one of those instead of a plain approve or reject.

Enter the outcome the step defines, and add comments if they help. An outcome the step does not define has no path to follow, so use this only where you know the route expects it.

What happens next

The decision is recorded against the task with your name, the time, and your comment, and the route moves to whatever comes after that step. When the last step completes, the request itself is settled in the section that owns it — a leave balance is committed, an enrolment is created, a pay run becomes ready to finalise. Every decision also lands in the decisions log, where it can be traced later.