Application ownership
Every application that reaches assessment belongs to somebody. Ownership decides whose queue it appears in, who is accountable for moving it along, and who an enquiry about it should go to.
This is internal to UAC and UNSW. There is nothing for you to call, and nothing you send changes. It is documented here because the fields you already send are what the rules read, so knowing that helps explain why one application is picked up promptly and another sits.
The rules
Ownership is decided by a list of rules, each one a condition and the group that owns the application when the condition holds. They are evaluated in order, and the first rule that matches wins. A rule can test:
Conditions combine with all and any, and compare with the usual operators, including “is one of” against a list. So a rule can say postgraduate applications for a Science program starting in Term 1 and name one team for them.
Nothing matching leaves the application unassigned. It is not given to a default team and not quietly dropped: it sits in the unassigned queue where somebody picks it up by hand. An application with no obvious owner is a question for a person, and guessing would put it in a queue nobody is really watching.
Ownership is evaluated when assessment begins, not when the application arrives, so the facts read are the ones current at that point. If you correct an application before it is assessed, the correction is what the rules see.
Assigning by hand
Officers assign as well, to themselves or to a colleague, and they can reassign at any time. A hand assignment beats the rules: a rule never overwrites a decision a person made.
The assign dialog leads with the assignees the rules suggest, so the common case is one click and the unusual case is still possible. Where ownership came from is recorded either way, so an application assigned by a rule reads differently from one a person took.
What you can see of it
Nothing, today. Ownership is not exposed on the application, the outcome or the change feed, and no endpoint reports it.
Mentioning it here is deliberate: the stream, intakeCode, year and programCode you
send are doing more work than routing an application into a pile. They decide who picks it up.
An application sent without an intakeCode, for instance, cannot match a rule that names one,
so it falls through to whatever more general rule follows, or to nobody. That is a reason to
send the optional fields even though the API does not require them.
