Training triggers

A completion record says a course was done. It does not say why it was assigned.

CORA's trigger register records why a worker needed training: the feedback, complaint, incident or identified risk behind it, the workers it concerned, and whether training followed. The decision to train somebody is almost always made somewhere else, in a complaint, a shift report, a near miss, a conversation at a team meeting, and then it is never written down beside the training it produced. This is where that link gets held, on the same worker record as everything else.

Which NDIS software records why a training course was assigned after an incident or complaint?

CORA Workforce does. CORA records the reason a course was assigned alongside the completion, so a provider can show an auditor not only that a worker was trained but what prompted it: a complaint, an incident, a piece of feedback or an identified risk. The reason stays on the worker record after the manager who made the call has left.

What is a training trigger register?

A family says a worker rushed a mealtime. An incident report gets written up on a Sunday night. A team leader points out that nobody rostered on Thursday has supported this presentation before. Every one of those is a reason to train somebody, and most of the time it does produce training.

What it does not produce is a record joining the two. The training register shows the course, the date and the worker. The reason lives in someone's inbox, or in a different system, or nowhere. So the question "what made you decide this worker needed this course" has to be answered from memory, by whoever happened to make the call, possibly eleven months ago.

A trigger register answers it from a record instead. One row per event: what kind of thing it was, the date it happened, your own reference for it, which workers it concerned, and what followed.

The four kinds, and the fifth you already have

CORA records four kinds of trigger: feedback, a complaint, an incident, and an identified risk. They are fixed categories rather than a free text box, which is deliberate. A register where every manager invents their own label is a register nobody can read back a year later, and reading it back is the entire point of keeping it.

The fifth input, the outcome of a worker's performance review, you already have. A supervision action in CORA can carry a course and assign it in the same step, so a review that produces training leaves its record in the supervision register rather than needing a second home. The two registers sit beside each other because they answer the same question from different ends.

What CORA records, and what it will not hold

This is not an incident system, and the form is built so it cannot quietly become one. There is no field for what happened. The reference is a short label, your own incident number or complaint number, and nothing longer. The narrative, the investigation and the findings stay in the system you already keep them in, and you can attach a link straight back to that record if you want one.

The subject of a row is always a worker. A participant or a family member can be the source of feedback or a complaint, and is never named, never described, and never the subject. That distinction is what makes feedback safe to hold here at all: a person saying something about a worker produces a record about that worker, and records about workers are the only kind CORA holds.

It is a privacy boundary and a scope limit in the same sentence, and it is worth being plain about both. CORA will not become your complaints system, and it will not hold anything about a participant. What it will do is record the workforce response, which is the part your training system is actually accountable for.

Three answers a row can give

A row says one of three things, in the register's own words:

  • Open. You have not finished responding yet. It is a status, not a finding.
  • Reviewed, no training required. You looked at it and decided no training was needed.
  • Training assigned, with the number of courses that followed.

The middle one matters more than it looks. "We considered this and assigned nothing" is a defensible answer and the usual one for positive feedback, and a register that cannot say it fills up with token assignments nobody meant to make. A blank cell, on the other hand, can reasonably be read as a lapse. So the decision gets named rather than left out.

Can I export the trigger register for an audit?

Yes. The whole register downloads as a CSV, and it is built from the same query the screen renders, so the file and the screen cannot disagree with each other.

What the trigger register exports
ColumnWhat it shows
DateThe day the thing happened, not the day it was typed in
KindFeedback, complaint, incident or identified risk
ReferenceYour own short reference, carrying no description of the event
Raised byWhere the record came from
Workers concernedNamed, because "these workers were involved" is the evidentiary point
Training assignedThe courses recorded against it
OutcomeOpen, reviewed with no training required, or training assigned
Link to source recordBack to your own system, where the narrative lives

It joins the audit-ready records CORA already exports, so "show me what your training responded to over the last twelve months" is a download rather than a fortnight of digging. See what a training register has to show.

Who can see the register

Admins. The register is an administrative surface, and workers do not see it. A worker who was named in a row will see any training that followed, in the ordinary way, on their own list of what is assigned.

Where the trigger register stops

CORA records that an event of a named kind occurred, which workers it concerned, and what training was assigned in response. It does not hold your investigation, it does not record a finding, and it does not rate whether the response was enough. The first two are yours. The last one belongs to an auditor.

The boundary that runs through all of CORA applies here too. CORA measures and evidences capability; it does not certify competence. Sign-off on whether a worker is competent on the job stays with your own qualified assessor, and for high intensity supports that assessment is clinician-led.

CORA does not guarantee an audit outcome. That depends on your whole quality system.

Included for every provider

There is one CORA plan, and the trigger register is in it. No add-on, no separate charge, nothing to switch on. Responding to what actually happens in a service is a baseline obligation rather than an upgrade, so it is not something to sell back to a provider who already has to do it.

Seat bands are published, 15 workers to 1,000, annual and ex-GST.

Common questions

No, and it is built so it cannot drift into one. There is no field for what happened. A row carries the kind of event, the date, your own short reference for it, the workers it concerned and whether training followed. The narrative, the investigation and the findings stay in the system you already keep them in, and you can link out to that record.

No. The subject of every row is a worker. A participant or a family member can be the source of feedback or a complaint, and is never named, never described and never the subject. A person saying something about a worker produces a record about that worker, which is the only kind of record CORA holds.

Four: feedback, a complaint, an incident, and an identified risk. They are fixed categories rather than free text, so the register reads back consistently months later. The fifth input most frameworks name, the outcome of a worker's performance review, is already covered through supervision, where an action can carry a course and assign it in the same step.

Yes, and it is one of the three states a row can be in. Closing something with no training recorded reads as reviewed, no training required, which is a defensible answer and the usual one for positive feedback. A register that cannot say it fills up with assignments nobody meant to make.

Yes. The whole register downloads as a CSV carrying the date, the kind, your reference, where the record came from, the workers concerned, the training assigned, the outcome and a link to your own source record. It is built from the same query the screen renders, so the file and the screen cannot disagree.

Included. There is one CORA plan and the trigger register is in it, with no separate charge and nothing to switch on. Responding to what happens in a service is a baseline obligation rather than an upgrade.

No. CORA records that an event of a named kind occurred, which workers it concerned and what training was assigned in response. It does not record a finding, it does not rate the response, and it does not guarantee an audit outcome. Whether the response was adequate is a judgement for your own quality system and for an auditor.

See where this sits in the rest of the record on what CORA does, read how the supervision register covers performance reviews, or enquire and look at the register itself.