Working through the approvals inbox
Approvals is the single queue for anything waiting on a person. Course access requests arrive here, as do publish checks, post-course competency sign-offs and anything else your account routes for a decision, so it is the one screen to check rather than several.
Where it is
Section titled “Where it is”Approvals in the main menu, with a count beside it when something is waiting.
What a row tells you
Section titled “What a row tells you”Each row shows the kind of request, who raised it, what it concerns and when it arrived. A course access request, for example, names the person asking and the course they want.
Opening a row shows the request in full, with whatever the requester said and where it has been so far.
The three decisions
Section titled “The three decisions”| Decision | What happens |
|---|---|
| Approve | The request is granted and then applied |
| Decline | The request ends; nothing is granted |
| Send back | It returns to the requester to change and resubmit |
Declining and sending back both require a reason. Approving does not.
Give a real reason anyway on a send-back. It is the only thing the requester receives, and “please revise” produces a resubmission identical to the first.
Approving is two steps, not one
Section titled “Approving is two steps, not one”Approving records the decision and then applies it — for a course request, that is what actually enrols the person.
The distinction matters because the two can come apart. If the decision is recorded and the applying fails, the request sits in a failed state: approved, but with nothing granted. It is not lost, and it does not need deciding again — it needs retrying.
Retrying is restricted to people connected to the request rather than to any administrator who can see it, so if you cannot retry one, you are not the person it belongs to.
Sending something back is not declining it
Section titled “Sending something back is not declining it”The two look similar and end very differently. Send back keeps the request alive and hands it to the requester. Decline ends it, and the requester has to start again from nothing.
Use send-back whenever the request could be right with a change, which is most of the time. Decline is for a request that should not have been made.
Approvals shared by several people
Section titled “Approvals shared by several people”Some approvals are offered to several people at once — a competency sign-off goes to every qualified assessor at the learner’s site. Choose I’m doing this to take one on: the others see that you have it and are told they no longer need to, though anybody can still act if you cannot. Where a step needs more than one signature, as many people can take it on as signatures are needed, and it completes when enough have approved. Any single decline ends it.
Competency sign-offs are recorded with Record sign-off rather than approved, and Sign off is only available once the sign-off form has been submitted. See Sign off a learner’s competency.
Deciding on your own request
Section titled “Deciding on your own request”Where your account routes a request back to the person who raised it, approving your own needs a specific permission, and the approval is recorded as self-approved so it can be told apart in reporting. Declining or sending back your own request is always allowed.
What happens after a decision
Section titled “What happens after a decision”The requester is told when something is sent back. Whether they hear about an approval or a decline depends on how your account’s workflow was built, so do not assume silence means nothing happened — see Publishing a course, and what a publish approval adds for the same behaviour on publish checks.