Student Allocations

Allocations control which logbook (level) each student may log treatments against. This guide covers open access in the free plugin, the Pro Student Allocations page, locking, and what students see when they are blocked. It is written for site administrators.

Open access vs allocations

In the free plugin there is no allocation step. Any logged-in user with one of your student roles can open the entry form and log treatments against any level you have set up. Free has no Student Allocations page, no locking and no allocation messages. To restrict which level a student logs against on Free, you rely on your own instructions to students.

With Pro active, allocations are opt-in. Installing Pro changes nothing for students until you create your first allocation:

• No active allocations anywhere on the site: entry stays open for every student, exactly as in Free. The Student Allocations page shows: “Heads up: while no allocations exist, every student can submit logbook entries. As soon as you create the first allocation, only allocated students can submit — allocate each active student, or keep this list empty to leave entry open for everyone.”
• At least one Active allocation exists: allocation gating switches on for the whole site. From then on a student can submit entries only for a level where they have an active allocation that is in date. The page then shows: “Allocation gating is ON: only allocated students can submit logbook entries. A student with no allocation — or whose allocation is archived — will be refused. Remove every allocation to reopen entry for everyone.”

Gating is on whenever at least one allocation has the status Active. To return to open access, delete allocations or change them all to Completed or Archived so that no Active allocation remains.

Before you create the first allocation, have the whole current student list ready to allocate. Students without an allocation are blocked from the moment the first one is saved.

🔒 Pro feature — requires the Pro plugin.

What an allocation is

An allocation links one student to one level, and optionally to a cohort at that level. Each allocation has:

Field	Meaning	Default
Student	A user with one of your student roles	— (required)
Cohort	Optional. Choosing one sets the level automatically and controls which trainers can see the student.	No cohort
Level	The logbook the student may log against	— (required)
Status	Active (“Student is currently logging treatments against this allocation.”), Completed (“Student satisfied the requirements for this logbook.”) or Archived (“Retired allocation; keep for auditing but hide from student view.”)	Active
Starts On / Ends On	Optional dates. When set, the allocation only counts between those dates, both days included. With no dates it shows as “Flexible window”.	Empty
Notes	Internal reminder, never shown to students	Empty
Locked	Whether new entries are blocked (see Locking allocations)	Unlocked

Only Active allocations give access, and only within their dates. If a new Active allocation would duplicate one the student already has, Pro refuses it.

The Student Allocations page

🔒 Pro feature — requires the Pro plugin.

Where to find it: wp-admin → Clinical Training Logbook → Student Allocations. Only administrators (Manage options) can open it. Trainers and students cannot.

From top to bottom the page shows:

1. Student role notice. This appears only if no users have a student role. It reads “No users match the eligible student roles yet. Update the Log Book settings to select the roles assigned to your students.” and lists the roles currently selected. The roles are set on Plugin Settings → Site Setup (see Plugin settings and pages).
2. Allocation Status. The count of allocations in each status across all students.
3. Automatic locking. The auto-lock setting (see Locking allocations).
4. Setup checklist. If you have no levels yet, or no users with a student role, the page shows Finish setup before creating allocations in place of the table. Each step is marked Complete: or To do:: add a level (on Logbook Configuration → Levels), give one or more users a student role in Users, then return to create an allocation.
5. Gating notice. The “Heads up” or “Allocation gating is ON” message described above.
6. Filters. Student, Cohort (including Orphaned — cohort deleted), Level, Status and Per page (25, 50, 100 or “All (max 200)”). Use Apply filters or Reset filters.
7. Allocations table. Columns: Student, Cohort, Level, Status, Window, Updated, Notes and Actions.

Row actions:

• View entries opens Logbook Entries filtered to that student.
• Edit changes the allocation.
• The ⋮ menu has Lock/Unlock, Move logbook…, Archive (not shown on archived rows) and Delete.

Row labels to watch for:

• No cohort — this student is not visible in any trainer’s workspace until allocated to a cohort. See Cohorts and cohort progress.
• Cohort #N (deleted) — edit this allocation to re-home it. The cohort was removed. Edit the allocation to choose a new one.
• Locked. New entries are blocked.
• (no longer student) after a name. The user still exists but no longer has a student role. Their history is kept.

The page needs JavaScript for creating and editing. A notice appears if JavaScript is off.

Creating allocations

🔒 Pro feature — requires the Pro plugin.

One form handles both a single allocation and a batch.

1. Select Add allocation. The Create allocation drawer opens.
2. Under Students, tick one or more students. Use Search students… to narrow the list, and Select all / Clear all for big intakes.
3. Optionally choose a Cohort (optional). Each cohort is listed as “Name · Stream · Intake”. Choosing a cohort fills in the Level automatically. If you leave it as “No cohort — allocate to a level directly”, the form warns: “If you leave this as “No cohort,” the student will not appear in any trainer’s workspace until you add them to one.”
4. Choose a Level if you didn’t pick a cohort.
5. Leave Status as Active to give access, and optionally set Starts On, Ends On and Notes.
6. Select Create allocation.

Batch results: each ticked student gets their own allocation. A student who already has an Active, in-date allocation for that level is skipped, and the message names them: “Already allocated to this level, so not changed: … To move them to a different cohort, open the existing allocation and edit its cohort.”

Validation messages:

• “Select at least one student and a level before saving.”
• “Select a valid student before saving.” / “Choose a valid level for this allocation.” / “Select a valid cohort for this allocation.”
• “Cohort level must match the allocation level.”
• “The end date must be after the start date.”
• “This student already has an active allocation for that level.”

The form’s footer says “Students gain access as soon as an active allocation exists for their level.” A future Starts On date delays access until that day.

Archived cohorts: the Create form still lists archived cohorts. Check that you haven’t picked one by mistake. The Edit dialog hides them.

Changing an allocation

🔒 Pro feature — requires the Pro plugin.

Edit

Select Edit on a row. The student and level are fixed. You can change Cohort (only cohorts at the same level are offered), Status, Starts On, Ends On and Notes. Select Update allocation to save, or Cancel edit to discard your changes.

Changing the cohort here moves the student’s membership only. The form explains: “Moving cohort starts a new logbook — entries already logged stay with the cohort they were done under.”

Move logbook…

Use ⋮ → Move logbook… when the student’s existing work should follow them, for example when a student defers to next year’s intake. In Move logbook to another cohort, choose Move to cohort, then select Move logbook and confirm: “Move this logbook and every entry already logged under it to the chosen cohort?” This moves the allocation and every entry this student logged at this level under the old cohort. Progress figures change for both cohorts. The Activity Log records it as Moved logbook entries.

Archive

⋮ → Archive sets the status to Archived after you confirm “Archive this allocation? Students lose access immediately.” The allocation and all entries are kept. The Activity Log records Archived allocation. Use this when a student finishes, withdraws or moves on.

Delete

⋮ → Delete asks “Delete this allocation? This cannot be undone.” You can only delete an allocation if the student has no entries at that level. Otherwise you see: “This allocation has treatments logged against it and cannot be deleted. Archive it instead, then create a new allocation.” The message also tells you how many treatments were found. Successful deletions are recorded as Deleted allocation.

History

Every create, update, archive, lock, unlock and delete is also written to an internal allocation history. It isn’t shown on any admin screen, but it is included when you run a WordPress personal data export for the student. It is removed if you erase that student’s personal data. See Evidence storage and privacy.

Locking allocations

🔒 Pro feature — requires the Pro plugin.

A lock freezes a student’s logbook for one level, for example while you mark it or once it is signed off.

• What a lock blocks: while an Active allocation is locked, the student can’t save entries for that level. This covers new entries and changes to existing entries at that level. The message is “This logbook is currently locked by your administrator. New entries cannot be submitted.”
• What it doesn’t block: viewing. Students still see their entries and progress, and you can still review, move or export them.
• Manual lock: ⋮ → Lock or Unlock on the row. A Locked badge appears. Each change is recorded in the Activity Log as Changed allocation lock.

Automatic locking

The Automatic locking box on the page has one checkbox: Lock a student’s allocation automatically when its level is complete. Select Save to apply it. It is off by default.

When it is on, the check runs each time a student saves an entry. If the student’s Active allocation for that level is not already locked, Pro checks the student’s progress against the clinic minimums for that level (see Program catalogue). The allocation locks when every clinic type with a minimum has reached its count. If that clinic type also requires treatment notes or a reflection, enough counted entries must have them too. A level with no clinic minimums never auto-locks.

You can unlock an auto-locked allocation manually at any time. Automatic locks are not recorded in the Activity Log.

What students see

Free: nothing changes. Students never see allocation messages.

🔒 Pro feature — requires the Pro plugin.

Once gating is on, a student with no Active, in-date allocation sees an Awaiting logbook allocation panel instead of the form or board:

Where	Message
Entry form	“Your program administrator must assign your next logbook before you can submit treatments.”
Progress overview	“Your progress board will unlock as soon as your next logbook allocation is applied.”
Usage insights	“Your usage board will unlock once your next logbook allocation is assigned.”

The panel links to Contact your program administrator, which opens an email to your site’s admin address.

If a student tries to save an entry for a level they aren’t allocated to, they see: “Your program administrator must assign this logbook before you can submit entries.” A student editing an older entry whose level no longer has an Active allocation can still save that edit, unless the allocation is locked.

Administrators testing the front end: if you aren’t allocated yourself, you see You have no logbook allocation with an Open Student Allocations link instead of the student wording.

When a student logs an entry, Pro stamps it with the cohort from their Active allocation for that level. This is how entries count toward cohort progress.

Troubleshooting

🔒 Pro feature — requires the Pro plugin.

Problem	Fix
Every student suddenly sees “Awaiting logbook allocation”	You created the first Active allocation, so gating switched on. Allocate the rest of your students, or remove or complete the allocation to reopen entry.
One student is blocked even though they have an allocation	Check Status is Active and that today falls between Starts On and Ends On. A future start date delays access.
“This allocation has treatments logged against it and cannot be deleted.”	Archive it instead.
Batch create skipped students	They already had an Active allocation for that level. Edit the existing allocation if you need to change its cohort.
A student can’t save after finishing	Automatic locking may have locked the allocation. Look for the Locked badge and Unlock if needed.

Worked example

🔒 Pro feature — requires the Pro plugin.

A college opens its 2026 Diploma intake of 28 students in February:

1. On Logbook Configuration → Cohorts, the coordinator creates “Diploma 2026” at Level 2 and assigns two clinic supervisors as trainers.
2. On Student Allocations she selects Add allocation and selects all 28 students, chooses the Diploma 2026 cohort (Level 2 fills in), and leaves Status Active. She sets Ends On to 30 November and selects Create allocation. All 28 are created in one go, and the notice now reads “Allocation gating is ON”.
3. She turns on Automatic locking so each logbook freezes when the student meets every Level 2 clinic minimum.
4. In June, one student defers to the 2027 intake. The coordinator uses ⋮ → Move logbook… to move the allocation and the student’s existing entries to “Diploma 2027”.
5. In December she archives the completed allocations. The Activity Log shows each archive with her name and the date.