Testing an application against the published criteria, and telling the applicant which one it failed
A licensing authority publishes what it requires, and an applicant is entitled to be told which of those requirements they failed. In practice the criteria get checked in several places at once — a clerk against the checklist, a technical department against its own rules, an officer against the regulation — and the reason for a refusal is often assembled after the decision rather than during it. Modeled as one orchestrated process, each published criterion is tested and cited at the moment it is tested, consultations are issued and their replies kept against the case, and the officer determines on a file where the basis for every result is already visible. The notice that goes back to the applicant names the criterion, because that is how the record was built.
A reference architecture: how RoboAgentix would model this process on UiPath. It is not a description of a delivered project, and no client, result or metric is implied.
What starts it
An application form and its attachments are submitted through a public portal, a service counter, or a channel that feeds one.
Why it is orchestrated rather than scripted
- Consultation replies arrive on each department's own timetable, and the process has to stay open across all of them rather than treat a slow reply as a failure.
- The published criteria are amended, and an application has to be judged on the version in force when it was submitted — which means the rule is a versioned artifact the process reads, not logic inside a robot.
- A refusal can be challenged, so the criterion applied and the evidence behind it have to be reconstructable long after the case is closed.
How it runs on UiPath Maestro
The process is defined in BPMN and Maestro runs it across agents, robots and people, holding its state for as long as the work takes — including while it waits on an approver.
Step by step
- 01
Application receivedSystem
An application and its attachments arrive from the public portal, a counter intake, or a channel that feeds one, and the submission time is fixed on the case.
- 02
Read and check completenessAgent
Attachments are classified against the checklist published for that permit type and their fields extracted with a confidence each, and anything missing or expired is named as a specific deficiency rather than a general one.
- 03
Test criteria and consultAgent
Every published criterion for that permit type is tested and cited, and where the rules require another department's view, a consultation is issued and the process waits for the reply.
- 04
Settled by the criteria?Maestro
The orchestrator routes on which criteria are met, whether every required consultee has cleared it, and whether the permit type is one the criteria settle outright.
- 05
Licensing officer determinesPerson
Anything not settled reaches the named officer with each criterion and its result, the consultation replies in full, and the draft notice.
- 06
Issue and notifyRobot
The determination is written to the licensing register, the permit or the refusal notice is generated from the approved template, and the applicant is told the outcome on the channel they applied through.
- 07
Decision issued and recordedSystem
The applicant holds a decision that names the criteria applied, and the criteria version, the consultations and the determining officer are written to the case record.
What each agent is allowed to decide
An agent is only useful in a governed process if its authority is written down. Each one below has a defined input, a decision it may make on its own, and the condition that obliges it to hand over.
Completeness Agent
Checks the submission against the checklist published for that permit type.
Reads
- The application form and every attachment
- The published document checklist for that permit type
- Validity dates and reference numbers the checklist depends on
Decides on its own
Must escalate when
Criteria Agent
Tests the application against the published criteria, one criterion at a time.
Reads
- The published criteria for that permit type, indexed for retrieval, at the version in force on the submission date
- The checked application file
- Reference data a criterion depends on, such as activity classification or site records
Decides on its own
Must escalate when
Consultation Agent
Works out which departments must be consulted and reads what they send back.
Reads
- The permit type and what the application proposes
- The consultation rules published for that type
- Each department's reply as it was written
Decides on its own
Must escalate when
What the robots do
Deterministic steps stay with robots — the same action every time, including in systems that never exposed a usable API.
Register robot
Writes the determination to the licensing register and generates the permit or the refusal notice from the approved template.
Runs in
Correspondence robot
Returns the outcome to the applicant, carrying the criterion behind a refusal and the route to challenge it.
Runs in
Settled by the criteria?
Every published criterion is marked met on the version in force when the application was submitted, every required consultee has cleared it without conditions, and the permit type is one the authority's recorded delegation allows to be issued on the criteria alone.
- Passes
- Issued under that delegation, in the officer's name, and the applicant is notified.
- Does not pass
- Sent to the named officer with every criterion, every reply and the draft notice, and the process stays open until they determine it.
Modeled as a decision table, so the threshold can be changed by the people who own the policy without redeploying an automation.
The human step
Who
What they see
What they decide
People are in this process because judgment or authority belongs to them — not as a fallback for a step that failed.
What this design deliberately does not do
An automation is only trustworthy if its limits are written down as plainly as its capabilities.
- It does not refuse an application. A refusal is the officer's decision; the design assembles the criterion, the evidence and the draft notice, and stops there.
- It does not apply an unpublished rule. If a criterion is not in the published set, no agent has anything to test it against and the file goes to the officer.
- It does not reinterpret a consulting department's reply. An objection or a condition is carried to the officer as written, not weighed against the criteria by an agent.
- It does not send the applicant a reason the officer has not seen. The notice text is drawn from the determination, not written separately after it.
Failure has a defined path
Systems go down, confidence drops, approvers go on leave. Each of these is a modeled branch rather than a stuck instance.
- The licensing register or a consultee's system is unreachable.
- The instance holds at that step instead of failing the application. The write stays on its queue and is retried, the applicant's status remains the last state that was actually true, and if the outage outlasts the wait the process is configured for, it is raised to the licensing team as a system exception — never recorded as a deficiency against the applicant.
- A criterion comes back undetermined, or a field is extracted below its confidence threshold.
- The gate cannot be satisfied, so the file routes to the officer with that criterion flagged, the evidence that was found attached, and the reason it fell short stated. Nothing is issued on a criterion nobody has resolved.
- A consulting department does not reply.
- The process keeps waiting and keeps the elapsed time visible on the case. At the point the authority's own rule allows, it either reminds the consultee or puts the file to the officer with that consultation marked outstanding, so the officer decides how to proceed rather than the silence deciding for them.
- The officer takes no action on the task.
- The task stays open and nothing expires into an issue. It escalates on the schedule the authority sets to whoever holds that officer's delegation, and the reassignment is written to the case alongside the original assignment.
Data, rollout, and what to watch
Data it touches
- Applications carry personal and commercial detail. The design keeps the file in the licensing system and the document store, and passes each step only the fields it needs rather than the whole submission.
- The retrieval index holds the published criteria and the authority's guidance, not applicant data, so an agent citing a rule is not reading anyone's application to find it.
- A consultee receives what the consultation requires — the proposal and the attachments within their remit — not the applicant's full file or the results of criteria outside it.
- Residency and retention follow the authority's own schedule. The case record is held for as long as the challenge window and that schedule require, and its deletion runs under the authority's control, not the process's.
How it goes live
- 01
Shadow
The process runs beside the existing one on live applications. Agents test the criteria and draft the notice; no consultation is sent, no register entry is written, no applicant is contacted. Officers determine as they do today, and each determination is compared against what the design would have recorded. The gate to the next phase is agreement on the criteria results, with a stated explanation for every case where they diverged.
- 02
Supervised
The process runs for real, but every application reaches the officer whatever the gate concluded — the clean path only changes how completely and how quickly the file arrives. Consultations, notices and register entries are made by the design on the officer's confirmation. The gate to the next phase is that criterion results and deficiency notices hold steady without officer correction across the permit types in scope, and that the authority has recorded which types its delegation covers.
- 03
Delegated issue, exceptions to the officer
Applications that meet every published criterion on a covered permit type are issued without a person. Everything else — a criterion not met or undetermined, an objection, a condition, any refusal — goes to the officer exactly as before. Permit types are added to the delegated set one at a time, each with its own supervised period, rather than as a group.
Signals worth watching
- The share of applications that reach the officer, and whether it drifts after the criteria are amended or a new permit type is added.
- How often the officer changes a criterion result the agent recorded, read per criterion — one criterion doing most of the changing is a wording problem rather than a model problem.
- The time consultations spend outstanding, per consulting department, including the ones that eventually cleared.
- Which requirement most often causes a deficiency to be returned to applicants, which points at the checklist or the form rather than at applicants.
Named without target values. What good looks like depends on your volumes and your risk appetite, and is set with you rather than asserted here.
The UiPath components this design uses
UiPath Maestro
Runs the BPMN process and holds its state for as long as the work takes, including while it waits on a person or a system that is down.
UiPath Agent Builder
Where each agent is defined — its instructions, its tools, its inputs and outputs, and the escalation that sends work to a person.
UiPath Document Understanding
Classification and field extraction, returning a confidence score per field that the policy gate can route on.
Context Grounding
A retrieval index over your own policies and reference data, so an agent cites the rule it applied instead of recalling it.
UiPath Action Center
Where a human step actually lands. The approver gets a task with the agent's reasoning and sources attached, and the process resumes on their decision.
UiPath Orchestrator
Schedules the robots, holds queues and retries, and issues the least-privilege credentials each automation runs under.
UiPath Integration Service
Connectors to the systems of record, so the process talks to them through a maintained integration rather than a bespoke script.
Systems it touches
- Public application portal and counter intake
- Licensing case and register system
- Document store for submitted attachments
- Departmental consultation channels
- Reference data the published criteria depend on
What the run leaves behind
- The application and every attachment exactly as submitted, with the time it was submitted
- The version of the published criteria in force at that moment, and the result recorded against each one
- Each consultation: who was asked, what they were asked, what came back, and when
- The determination, the criterion behind it, and the notice the applicant received
- Every deficiency returned to the applicant and what they sent in response
Other representative workflows
Talk to us about a process like this.
The most useful first conversation is about a real process — where it stalls, who approves what, and which systems it touches.