A guide to allocating a placement cycle — from platform export to decided workbook.

1. What the tool does — and what it does not do

2. Before you start — the file you need

3. The five-minute version — the whole process on one page

4. Loading your export — including fixing unrecognised columns

5. Setting the rules — every setting explained

6. Running the allocation

7. Reviewing in the calendar

8. Reviewing in the requests table — and changing a decision

9. Warnings — what each one means

10. The summary

11. Exporting your results

12. Saving and reusing your rules

13. If something goes wrong

Every six months you export around a thousand placement requests from the placement platform, work through them deciding which to accept, and colour the spreadsheet green and red. This tool does that middle step for you.

You give it the export. It applies your rules and returns a recommended accept or decline for every request, each with a plain-English reason. You review the result, change anything you disagree with, and export a workbook in the same green and red format you use now.

A few things it deliberately leaves to you. It does not know about placements agreed outside the export you give it, it does not action anything in the placement platform, and it never makes a decision you cannot change. Where a judgement call is genuinely yours — filling a shift with a different year group, say — it tells you what it would take and lets you decide.

You need one file: the requests export for the cycle you are allocating, straight from the placement platform. Both .xlsx and .csv work.

The tool looks for these columns. It finds them by name, so their order does not matter, and extra columns are ignored and passed through to your export untouched.

If you have used the tool before and just need the sequence:

1. Open it from the link provided by the Med App team and drag your export onto the page.

2. Check the rules down the left. If you have used the tool before, they are exactly as you left them.

3. Press Run allocation. It takes about a second for a full cycle.

4. Look at the Warnings tab first. Anything under "Rule breaches" needs your attention; anything under "Things to look at" is a judgement call.

5. Work through the Calendar and Requests tabs, overriding any decision you disagree with.

6. Press Export decided workbook and use it to action the requests in the platform.

Drag the file anywhere onto the page, or click to browse.

The opening screen. Drag your export anywhere onto this panel.

The tool finds the header row itself, skipping any report title or blank rows above it, and works out which column is which. Blank separator rows between units are ignored.

Open the Column mapping panel on the left. Each field has a dropdown listing every column in your file — point it at the right one and the tool re-reads the file immediately.

Column mapping. Fields marked with a pink asterisk are required.

You will only need this if the platform changes its export format. The tool recognises a wide range of headings — Ward, Department and Clinical Area all resolve to Unit, for example — so most changes will not trouble it.

Everything the engine does is controlled from the left-hand panel. Nothing is fixed in the tool — every rule below can be changed, switched off, or set to warn you instead of declining.

Your settings are remembered in this browser, so you normally only need to do this once and then adjust it each cycle.

One facilitator is supplied for every eight students, so a shift carrying fewer than eight risks losing its facilitator altogether.

The tool counts, for every single day of a placement, how many students are on that shift. Where a day falls short, it removes the lowest-priority placement on that shift and checks again, until every shift that is running meets the minimum.

Your priority partners are placed first, in the order shown. Drag a provider up or down to change its rank, or use the small arrow button to move it between the ranked and unranked lists.

Everything in the unranked list is considered only after the ranked partners have been placed. That is what gives your core partners first call on the units they want.

A ward needs to handle one year group consistently across the day. Having second-years in the morning and third-years in the afternoon on the same ward changes supervising and facilitation needs between shifts.

This rule keeps both shifts on a ward carrying the same cohort. It reads the year level from the Student Category column, so Nursing 2 is a year 2 group and Nursing 3 is a year 3 group.

This rule never forces a pair. A ward can legitimately have the morning filled and the afternoon empty. Where a shift is left empty because nothing compatible was available, the tool tells you so in the Warnings tab and lists the requests it turned away, so you can put one in by hand if the ward can take it.

This panel lists every student category found in your file with the year level and stream the tool has read from it. Graduate-entry groups are treated as the equivalent nursing year, so GEM 2 sits alongside Nursing 2.

If a future export introduces a category the tool reads wrongly, correct it here. Your corrections are saved with your rules.

Periods when no placements should run — the new-graduate intake weeks. The tool sets these up for every year it finds in your file. Change the dates, rename them, add periods or remove them as you need.

The dropdown underneath controls whether a request is declined because it runs through a blackout at any point, or only if it actually starts inside one.

How many students each unit can take, morning and afternoon separately. The tool works these out from your file — universities generally request exactly the capacity available — but you can change any figure or add a unit that is not in the export.

Block length sets the longest placement you will accept, with an exemption for very small units where a single student sitting in a specialty area for six weeks blocks nobody. Set it to 0 for no limit.

Distribution preference decides how the engine breaks a tie. Spread evenly across the cycle pushes placements apart so a unit is used throughout the year. Minimise gaps does the opposite, keeping blocks back-to-back.

Allow concurrent blocks lets more than one group share a unit at the same time, up to its capacity. Off by default, which means one block at a time per unit and shift.

Press Run allocation. A full cycle of a thousand requests takes about a second.

A message appears at the top telling you how many were accepted and declined, and whether anything needs your attention. If you change a rule afterwards, the button changes to Re-run allocation as a reminder that what you are looking at is now out of date.

The engine works in a fixed order, and the first rule that turns a request down is the reason recorded against it:

The same file and the same rules always produce exactly the same result.

The calendar is the fastest way to see the shape of a cycle. Units run down the side, split into morning and afternoon; time runs across the top.

The calendar view. Green cells are placements; peach cells are requests that were turned down.

The two rows at the bottom are worth your attention. They show the total students on the morning and afternoon shift across every unit — the figure the facilitation minimum is measured against, and the thing that is almost impossible to see on paper. An amber figure is a shift below the minimum.

The footer totals: students on shift across all units, week by week.

Hover any cell for the detail. Click one to jump to that request in the table. Use the controls above to switch between a weekly and daily view, focus on a single unit, or hide units with nothing in them.

Print / PDF produces a clean landscape copy of the calendar with the sidebar and controls stripped out.

The table lists every request with its decision and the reason for it.

Every request, with the reason for its decision and a button to change it.

Search across units, providers and reasons, or filter by decision, unit or provider. Searching for a rule name — "blackout", or "cohort" — brings up everything that rule turned down.

Underneath each student category you will see the year level and stream the tool has read from it, so you can tell at a glance if a category has been misread.

Every row has a button that flips its decision. Use it whenever your judgement differs from the engine — most often to fill a shift the rules left empty.

A changed decision. The row is highlighted, badged as an override, and the original reason is kept.

Changed rows are shaded pink and badged so they never get confused with the engine's own decisions, and the reason records what the engine had said. Reset puts a row back.

The moment you change something, every rule is checked again. If your change creates an overlap, breaches a capacity, drops a shift below the minimum or mismatches a ward's cohort, it appears in Warnings immediately. Nothing stops you — you are told, and you decide.

Clear all overrides returns every row to the engine's decision.

The Warnings tab is the first place to look after a run. It is split in two, and the distinction matters.

Warnings, split into genuine rule breaches and judgement calls.

Something here breaks a rule you have switched on. In a clean run this section is empty — breaches almost always come from a decision you changed by hand, or from rows in the source file the tool could not read.

Not breaches — judgement calls the tool deliberately leaves to you.

Every warning has a button that takes you straight to the requests involved.

A cycle at a glance: totals, then a breakdown by university, by unit, and by the reason requests were turned down.

Summary totals and the AM/PM pairing figures.

The pairing panel tells you how many wards have both shifts running over the same dates, how many of those mismatch on year level (which should be zero unless you have overridden something), how many span two universities, and how many shifts were left unpaired.

The breakdown by university is the one to check if a partner queries their allocation — it shows requests, acceptances, declines and total student places for each.

Your original file with every column exactly as it was, coloured green for accepted and red for declined in the convention you already use, plus three columns: the decision, the reason, and whether you changed it by hand. This is the one you work from when actioning requests in the platform.

A compact list of every request and its decision, keyed on the request ID if your export has one. Intended for bulk upload if the platform ever supports it.

Opens your browser's print dialogue with the calendar laid out in landscape. Choose "Save as PDF" to keep a copy, or print it for a planning meeting.

Your rules are remembered in this browser automatically. Come back next cycle on the same computer and everything is as you left it.

Export rules saves them to a small file. Use it to keep a copy of the ruleset you used for a particular cycle, to move your settings to another computer, or to share them with a colleague. Import rules loads one back. Reset returns everything to the defaults.

If the tool reports an unexpected error, or the results do not make sense, contact the Med App team. It helps enormously if you send the export file you were using and your rules file, exported with the Export rules button — together they let us reproduce exactly what you saw.