Finishing work · LendEasy Docs

How a task is completed: the outcome catalogue the server publishes with each task, what it demands, and what happens to work a person cannot finish.

Every task is completed through one dialog, whatever screen the work was done on. The dialog renders, for each available outcome, the check the server will run when that outcome is submitted — before the agent selects one.

What each outcome declares

Whether a note is requiredAnd whether evidence isevidence is chosen from the case’s own documents by name, not entered as an identifier

Which case fields must be completedNamed in advance

The check the server will runRendered as a sentence"Checked: the lending core has reported this account current."

Whether follow-up work is requiredRequired, optional or forbidden

The check is shown before selection rather than returned as a rejection, so an agent who cannot satisfy an outcome discovers it before committing to it.

The outcome catalogue

The task carries the fixed list of ways it can end. There is no free-text status and no other option. Where the catalogue is enforced, it is the only way to complete the task.

The checks cover outcomes that assert something happened outside the task itself: an interaction was sent or logged, an arrangement exists against the case, the lending core executed a governed change, the lending core reports the account current, a verification session passed, a compliance decision was recorded, an action request was resolved.

Selecting arrangement agreed without an arrangement on the case is refused at submission. The condition is stated under the option before it is selected.

Where a case is pinned to a particular workflow version, the catalogue narrows to the outcomes that version can route onward from, and the response marks it as narrowed.

Work done in place

Seven kinds of work are performed in a panel rather than by navigating elsewhere: reviewing an inbound message from an unidentified sender, reviewing a document, confirming a protective hold applied, approving a hardship, adjudicating a monitoring match, logging an inbound call, and confirming a disaster declaration.

Each panel prepares the result and hands it to the same completion dialog with the matching outcome preselected. No panel completes a task itself, so there is one completion path and one release path however the work was done.

Held work and recovery

Where a person cannot complete work a workflow step owes — the borrower is uncontactable, the document will not arrive, the step is wrong for this case — the work is held rather than cancelled. It carries a held reason and time, is not offered to anyone else, and raises a recovery review for somebody with the authority to resolve it.

That reviewer has five options, each of which both moves the case and settles the review:

Five ways out, and the case moves under all of them

1Put it backanyone eligible can pick it up again — the step still owes the work
2Give it to someonethe same work, on a named person’s or team’s plate
3Skip the stepthe work is superseded and the case moves on — only to stages this case’s workflow already routes to from here
4Close the casethrough its ordinary closing rules, not around them
5Close it and open a manual casea checklist a person works through, with nothing automated behind it

Skip offers only the stages this case's workflow already routes to from its current position. The last option replaces the case with a manual one — a checklist worked by hand, with no automation behind it.

After completion

The dialog returns a receipt naming the recorded outcome and offers to pull the next task from the same queue. It is an offer rather than an automatic assignment. Work still arrives both ways — pushed by the dispatcher, or pulled when somebody asks for the next thing — and this dialog only ever offers, never assigns.

How a piece of work ends

The agent picks an outcomefrom the server’s list, knowing what each one will demanda person
They attach the note, evidence and fields it nameda person
The platform verifies its own claimsomething was sent, an arrangement exists, the core executed itautomatic
The outcome is recorded and the case re-evaluatedthe workflow decides what comes nextautomatic
Next work is offered from the same queuewaits