Training: Training Requests

This guide covers an employee asking to attend training, the approval decision, and how an approved request becomes a scheduled session.

---

Purpose

This answers the employee's question — "How do I ask for this course, and where does my request stand?" — and the manager's: "What is my team asking for, what will it cost, and is it justified?"

---

Raising a Request

A request is raised from Training → Training Requests, or from the Request Training button on My Trainings. It carries:

• The employee it's for.
• A program from the catalog, or a free-text title for something not in it. One of the two is required.
• A reason — why the training is needed.
• Preferred start and end dates — an indication for whoever schedules it, not a booking. The end date can't be before the start date.
• An estimated cost.
• An optional attachment — a provider quotation, a course outline, a syllabus.

The people who can decide it are notified as soon as it's submitted.

---

The Approval Decision

A request is Requested until somebody decides it. From there it becomes:

Status	How it gets there
Approved	An approver approves it. The requester is notified.
Rejected	An approver rejects it, with a reason — the reason is required, and is shown to the requester.
Cancelled	The requester withdraws it themselves, before it's decided.

Two rules keep the decision clean:

• A decision is final. Once a request is approved, rejected, or cancelled, it can't be decided again or edited — including in a bulk approval, where already-decided requests are skipped and reported back.
• Editing stops at the decision. A requester can correct their own request while it's still pending; afterwards they can't.

---

Who Can Approve

Either of:

• The requester's reporting manager, or
• Anyone holding the training approval permission — typically HR.

Being a manager of some team is not enough. A manager can only decide requests raised by the people who report to them. Everyone else who can see the request — an administrator with view-only access, for example — sees it without the approve and reject buttons.

---

Comments

Every request has a comment thread. Anyone who can open the request can read and add a comment; a comment can be removed by whoever wrote it, or by an administrator holding the comment-delete permission. This keeps the back-and-forth about a request — "which vendor?", "can this wait until Q3?" — attached to the request itself.

The thread is exactly as private as the request. Reading it takes the same three things that opening the request takes: being the requester, being entitled to decide it, or holding the request-view permission. Nobody else can read a thread, or post to one.

---

Scheduling an Approved Request

An approved request that hasn't been scheduled yet shows a Schedule action for whoever can create sessions. It opens the session form pre-filled from the request:

• The title and program.
• The preferred dates, as the session's start and end.
• The estimated cost, as the session's cost.
• The requester, already on the attendee list.

Saving it creates the session and links the request to it. The request then reads as delivered rather than merely approved — and, from that point, the session's real cost is what counts against the budget instead of the request's estimate.

---

Your Request Views

Training → Training Requests has two tabs:

• My Requests — everything you've raised, whatever its status.
• All Requests — your team's requests if you're a reporting manager, or every request company-wide if you hold the view permission. The tab is hidden from anyone who is neither.

Both can be viewed as a list or as cards, filtered by status, employee, program, or date, and grouped.

---

What Each User Sees

Action	Employee	Reporting Manager	HR Administrator
Raise a request for themselves	✅	✅	✅
See their own requests	✅	✅	✅
Edit their own pending request	✅	✅	✅
Cancel their own pending request	✅	✅	✅
See their team's requests	—	✅	✅
Approve / reject their team's requests	—	✅	✅
Approve several at once	—	✅ (their reports)	✅
See every request company-wide	—	—	✅
Comment on a request they can open	✅	✅	✅
Schedule an approved request into a session	—	—	✅
Delete a request	—	—	✅

---

How Visibility Is Decided

1. Ownership. The requester always sees their own request, its full history, and its comment thread.
2. The reporting line. A manager sees, and can decide, the requests of their direct reports — and reads those threads.
3. Permissions. The request-view permission grants company-wide visibility; the approval permission grants the right to decide any request; deleting has its own permission.
4. Company. A request belongs to the company of the employee who raised it.

The same test governs the request page and its comment thread, so there is no way round one by asking for the other.

---

Good to Know

• Cancelling and rejecting are different actions with different owners. The requester cancels; the approver rejects, and must say why.
• A rejection reason is mandatory. An empty one is refused.
• Bulk approval respects the same authority rule. Selecting several requests and approving them decides only the ones the approver is actually entitled to decide; the rest are skipped, and the count of skipped requests is reported.
• Preferred dates are a preference. Nothing stops a session being scheduled on different dates.
• The decision is on the record. An approved or rejected request shows who decided it and when, alongside the rejection reason where there is one — and, once scheduled, a link to the session it became.

---