11 September 2026

Management Portal

A space for academic authorities

Academic staff who rule on credit now have their own area of the portal, opened by the advance_institution_academic_authority role. It has three parts:

• a dashboard of the applications escalated to them, longest wait first
• applications, where they read every credit decision on an application but act only on the ones escalated to them, and can award credit themselves
• RPL — credit agreements, mappings and rules, narrowed to their own programs

An academic sees nothing of the credit team’s screens, and nothing belonging to a program they are not responsible for.

Awarded credit is approved and paired, not pending

Credit the assessment pipeline awards is approved. It is also paired with the academic responsible for it, but a pairing asks nobody anything, so configuring an authority no longer holds up the applications it touches.

The credit team reviews the credit and chooses: change the units, approve it provisionally, mark it exempt, reject it, or escalate it to an academic when they would rather not make the call. Only an escalation makes anything wait. Manual credit an officer creates can be escalated the same way.

An academic’s answer is final

Once an academic has accepted or rejected a credit decision, the credit team cannot change it — no re-pricing, no exempting, no rejecting, and no editing or withdrawing escalated manual credit. If a decision genuinely has to be revisited, the way back is to escalate a new one.

This is the point of escalating at all. An answer the credit team could quietly overturn afterwards is not one worth asking for, and the record would otherwise show an academic’s name against a figure they never agreed to.

Working by intake

An application now records the intake the applicant is starting, picked from your own intake schedule, and officers work applications in intake order — the term beginning in a fortnight before one eighteen months out. It appears on the applications list as a sortable column, on the application itself, and on the create form. Intakes under Configuration lists every intake we hold for you, with its start and end dates and whether it is upcoming, running or finished.

Searching the subject catalogue

Naming a UNSW course as the credit being granted meant typing its code, its title and its credit points by hand, out of the handbook. The code field now searches the subject catalogue: type part of a code or part of a name, and picking a subject fills in the other two.

It works when authoring a credit mapping and when a credit officer awards credit manually against an application.

Codes we have not loaded can still be typed in. The catalogue we hold is a snapshot of one year, and credit mappings outlive it — of the target course codes in the mappings today, around one in seven names a subject that is not in it. So the search assists typing rather than replacing it.

Smaller things

• Applications leads with the applicant’s name rather than the program code, which was identical on every row, and has a search across applicant, program, intake, status and any of your references. Program and cohort are one column now, and the row actions are buttons.
• Applicant details was rebuilt to match the layout of the application page, and an applicant’s name links through to it from the applicants list.
• Several of your references can be recorded and edited wherever an applicant or an application is created or corrected, not just one.
• Rejected credit sits in its own section on the Result tab, so what was granted reads cleanly.

Institution API

Several references per record

An applicant or an application can now carry one reference per system of record rather than one in total. Send them as sources, in the order you want:

{
  "sources": [
    { "sourceName": "SITS", "sourceRef": "z1234567" },
    { "sourceName": "TRIM", "sourceRef": "T-99814" }
  ]
}

Accepted on create and on PATCH, and returned on every applicant and application response. sources replaces the whole set, so an entry you leave out is removed and [] clears them; omitting the field leaves every reference alone. The first entry is the primary — what list views, search results and the change feed show. Details.

Two behaviours are stricter, both of them fixes:

• Submitting a duplicate reference is now refused. The check used to look only at a record’s primary reference, so an application quoting a sourceRef we already held against a second system got through and created a duplicate. It is now a 409 naming the record that holds it.
• References sent with an applicant we already know are kept. If we match your applicant on name and date of birth rather than on a reference, the references you sent are added to that applicant instead of being discarded.

The intake an application is for

intakeCode on submit and on PATCH records the term the applicant is starting, using your own code for it:

{ "intakeCode": "5269" }

Responses carry intakeCode and intake, the intake’s name:

{
  "intakeCode": "5269",
  "intake": "Term 3 2026"
}

These are your term codes, loaded from the intake schedule you supply us, so a code you use is a code we hold; one we do not recognise is a 400 naming it. Optional, but worth sending — our officers work applications in intake order, and one with no intake cannot be prioritised against the rest.

Unlike programCode, year and stream, the intake can still be corrected after an application has been assessed: nothing is assessed against it, so changing it leaves the credit already granted true. It is also not the commencement year — year picks the programme and the credit rules, intakeCode says which term the applicant starts, and an application sent in 2026 for Summer Term 2027 has both. Details.

Provisional credit

provisional: true on a credit marks it approved but conditional — the applicant receives it once they have completed the further study note describes, usually a year later.

It counts. status stays granted, uoc is what it is worth, and totalCreditUoc includes it, because it stands unless the condition is not met. A separate field rather than a fourth status value, so this credit still reads as granted to anything written before it existed.

Read it when you are telling an applicant what they hold today; ignore it when you are reconciling totals. Details.

Academic approval: escalation, and two new outcome fields

Credit the pipeline awards is approved. It is also paired with the academic staff responsible for it, but a pairing asks nobody anything — the credit team reviews the credit and escalates a decision only when they would rather an academic ruled on it.

Two fields tell you when that has happened:

• awaitingAuthority on the outcome — true while any of its credit is waiting on an academic. That credit is counted in totalCreditUoc, because it stands unless refused, so while this is true the total can still fall. finalOutcome is false whenever it is true.
• authorityState on each credit — awaiting, confirmed, refused, or null for the normal case where nobody was asked.

A refused decision reports uoc: 0 and status: rejected, with assessedUoc carrying what it would have been worth.

Details.