Skill-Based Rostering: Why the Roster and the Training Record Have to Talk to Each Other

6am, a shift needs filling. Someone has called in sick, or a new participant has started and nobody has worked out who covers it yet, and whoever is building the roster does the thing every roster gets built on: they ring around until someone says yes. The person who answers the phone gets the shift. Nobody on that call asked whether their manual handling was current, or whether they had done the training for the person's seizure management plan, or whether their first aid lapsed the previous Tuesday. There was no moment built into the process where that question could even be asked.

That is not a story about a careless rostering coordinator. It is the normal shape of the job, done under time pressure, with the tools most providers actually have. The training record lives in one system. The roster lives in another. Nothing reconciles them until an auditor does it for you, and by then the shift has already happened.

What skill-based rostering actually means

In short: skill-based rostering fills a shift with a worker who is currently trained and credentialled for the support it requires. Availability-based rostering, the default almost everywhere, only checks whether someone is free. The two overlap most of the time, and the gap between them is exactly where a compliance finding or a genuinely unsafe shift comes from.

Every roster answers a question, and the question most providers are actually answering is "who is free." That is not wrong, it is simply incomplete. A shift has requirements beyond a worker's availability: it might need someone trained in a specific person's PBS plan, someone with a current medication administration sign-off, someone who has done the manual handling assessment for a particular transfer, or someone who holds the credential a higher-risk support demands.

Skill-based rostering is the discipline of checking that second layer before the shift is confirmed, not after. It does not replace availability as the first filter. It sits underneath it, narrowing "who is free" down to "who is free and current," which is the actual question a provider needs answered.

Skill-based vs availability-based rostering

In short: availability-based rostering is faster and it is what almost every provider runs on by default. Skill-based rostering adds one more check. The honest reason providers skip it is not that they do not care, it is that the information to do the check usually is not sitting where the roster gets built.

That last row matters. Skill-based rostering is not a different way of filling shifts automatically. It is the same human decision, made with the right information in front of the person making it, instead of without it.

Why it matters under the NDIS Practice Standards

In short: the Practice Standards do not name a rostering process. What they require is that a provider can show its workers are appropriately skilled and trained for the role they perform, and for high-intensity or higher-risk supports that requirement does not stop at a job title. A shift filled by someone without the current credential is a gap that surfaces at audit, after the fact, because nobody checked before the shift ran.

The NDIS Practice Standards require a provider to demonstrate its workers are appropriately skilled and trained for the role they perform. That is deliberately general, and most providers meet it at the level of the role: a support worker completes an induction pathway, a team leader completes a leadership pathway, and the register shows it. For high-intensity and higher-risk supports, the bar sits a level lower than the role, at the specific support being delivered on a specific shift. Someone can be fully trained for their job title and still not be the right person for the shift in front of them.

That is the whole argument of this piece, stated plainly: the role is not the shift. A training register that shows a worker is current on their role-level pathway tells you something true and useful. It does not tell you whether that worker is current for the particular support they are rostered on this week, and that second question is the one an auditor, or worse, a genuinely difficult shift, will actually ask.

Worth being direct about where this sits. Confirming a credential is genuine, and deciding whether a specific worker should be rostered on a specific shift, both stay with the provider. No record, however current, removes that judgement call. What a record can do is make sure the judgement is made with the right information, rather than made blind.

The three things you need before it is even possible

In short: skill-based rostering is not a feature you switch on. It needs three things in place first, a current credential register, a mapping from role or support type to what it actually requires, and a way for that information to reach whoever builds the roster, before the roster is published. Miss one of the three and the check cannot happen, no matter how good the intention is.

1. A credential and training register with real expiry dates. Not a sense of who is probably up to date. A named record, per worker, that states what they hold and when it lapses. Without this there is nothing to check against. This is covered in full in NDIS credential tracking: worker screening, first aid and expiry dates.
2. A mapping from role or support type to the credential or training it requires. Someone has to have decided, in advance and in writing, that this support type requires that credential. Without the mapping, a current register just tells you what people hold, not whether what they hold is the right thing for the shift.
3. A way for that information to reach whoever actually builds the roster, before the shift is confirmed. This is the step almost everyone skips, because it is the one that needs two systems, the training record and the roster, to be looking at the same worker at the same time. Without it, the first two steps produce a correct, current, well-maintained register that nobody consults until the audit.

Most providers that think they cannot do skill-based rostering actually have the first two pieces and are missing only the third. That is the gap worth naming, because it is the one that is solvable without replacing anything.

Why the gap forms in practice

In short: the training record and the roster are usually accurate, just not accurate to each other. One person runs the register, on a compliance clock. A different person runs the roster, on an operational clock, usually at speed, usually by phone and text. Nothing reconciles the two until somebody does it by hand, and in most providers that somebody ends up being the auditor.

This is not a story about anyone being careless. The person running the training register is doing their job well, chasing renewals, uploading certificates, keeping dates current. The person building the roster is also doing their job well, filling gaps fast under real pressure, often with three other things happening at once. Each of them is accurate on their own terms. Neither of them is looking at the other's system while they work, because nothing puts the two in front of the same person at the same moment.

Expiry dates sit in a spreadsheet, or a folder, or a different platform entirely, and the roster gets built from whoever is free this week. Nobody finds out the two have drifted apart until someone goes looking, and the people most likely to go looking are an auditor, or a family, after something has already gone wrong. That is the ordering problem at the heart of this. The check that matters happens after the shift, not before it.

What a provider can do now, before any integration

In short: a provider does not need a connected system to start closing this gap. Naming which credentials each support type actually requires, setting expiry warning windows with enough runway, and reviewing upcoming rosters against expiring credentials on a standing schedule will catch most of the problem on their own.

Four things worth doing this month, in roughly this order.

• Name the credentials each role or support type requires, in writing. Not "support workers need training." Which training, for which support, delivered by whom. If this list does not exist yet, it is the actual first step, ahead of any system.
• Set expiry warning windows that give enough runway to act. Roughly 90 days for anything with an application process, like a worker screening renewal, 30 to 60 days for a course that can be booked, and 7 to 14 days as a last call rather than a first one. The full reasoning is in credential expiry tracking.
• Review the roster against expiring credentials on a standing cadence, not after a problem. A weekly ten-minute check, who is rostered in the next fortnight against what is expiring in the next fortnight, catches the vast majority of what otherwise surfaces at audit.
• Put the two records side by side before publishing a roster that reaches further than a week or two out. Longer-range rosters are exactly where a credential can lapse between the day the roster was built and the day the shift runs.

None of this requires new software. It requires treating the training record as something the person building the roster actually looks at, rather than something that exists for the next audit.

The skill a roster can't see: relational fit

In short: a worker can hold every credential a support requires and still be the wrong person for that household, that person, that day. Relational fit is a real dimension of skill, and it is the hardest part of this whole picture to systematise, which is exactly why it has its own guide rather than a paragraph here.

Everything above this section is about whether a worker is current for a support. Fit is a different question entirely, whether this particular worker and this particular person actually work well together, and it rarely shows up in a credential or a training record at all. It deserves proper treatment rather than a rushed mention, so it has its own piece: The skill a roster can't see: matching support workers to the people they support.

What a rostering connection does and does not do

In short: connecting a training system to a rostering system closes the third gap, getting the information to the person who needs it, before the shift is published. It does not, and should not, make the rostering decision for anyone. That decision carries pay and notice obligations as well as a duty of care, and both of those stay with a person.

That right-hand column is not a limitation that slipped through. It is the position, stated on purpose. Reassigning a shift is an industrial act as much as a records one, it can trigger minimum engagement pay and notice obligations under the SCHADS Award, and a system matching two rows of data has no business making that call. The decision belongs to a person who can see the whole roster, the whole team, and the whole situation. What should move automatically is the information. What should never move automatically is the shift.

How CORA connects to rostering

In short: CORA integrates with ShiftCare today, reconciling the worker list and raising new starters and changes for a person to confirm, with credential and training status flowing back out to where the roster is built. It is not an automatic two-way sync and it never writes a shift. Further native integrations are being built, and a system outside ShiftCare can be built against on request.

CORA holds the credential and evidence register with real expiry dates and warning windows, and training pathways assigned by role, which is the first two pieces of the three described above. The third piece, getting that information to whoever actually builds the roster, is what the ShiftCare connection is for.

An administrator connects their ShiftCare account, and CORA reconciles the worker list against it. Anyone new, or anyone whose details have changed, comes through as something for a person to confirm rather than being created silently, which matters more than it sounds: two workers sharing a household email, or an agency address turning up against several people at once, is exactly how one person's compliance record ends up attached to somebody else. Once a worker is confirmed, their credential and training status flows back out to ShiftCare, so whoever is building the roster can see what is current without opening a second system or waiting on an email from compliance. CORA can then show who is rostered on upcoming shifts while a required credential or training item is not current, which is the visibility a provider actually needs at the point a roster is being built, not after it runs.

None of that touches the roster itself. CORA does not write a shift and it does not block one. Who ends up on a shift is a decision for a person, made with better information than a spreadsheet and a memory can supply, not a decision handed to a system.

More native integrations are being built. If the system you roster or pay from is not ShiftCare, tell us which one. CORA's developer team builds custom integrations on request, against a real customer and a real system rather than in the abstract, which is a more honest answer than a release date nobody can keep. Short of a direct connection, training and credential status export as CSV for any date range, so the two records can still sit side by side.

This guide is general information for NDIS providers, not legal or compliance advice. Rostering and pay obligations sit with the Fair Work Ombudsman and the SCHADS Award as well as the NDIS Quality and Safeguards Commission, and both move, so confirm the current requirements directly rather than relying on this guide, or any other, as the final word.

Sources and further reading

• NDIS Practice Standards, NDIS Quality and Safeguards Commission
• NDIS Workforce Capability Framework, NDIS Quality and Safeguards Commission
• Social, Community, Home Care and Disability Services Industry Award (MA000100) summary, Fair Work Ombudsman
• The skill a roster can't see: matching support workers to the people they support, CORA
• NDIS credential tracking: worker screening, first aid and expiry dates, CORA
• NDIS training register: what it must contain and how to keep one, CORA
• High-intensity support skills: where eLearning helps, and where it can't, CORA
• How to manage an NDIS workforce: visibility, delegation and automation, CORA
• NDIS staff training requirements: the 2026 provider's guide, CORA
• Integrations: connect ShiftCare to CORA, CORA
• Common questions from providers, CORA