Trying it out

What you are looking at

The system has two halves, and this round of testing is the first time you can walk both of them end to end.

The team queue is the screen you saw on 6 August. The exemptions spreadsheet is on it in full, 158 applications, nearly all of them from 2026, with where each one has got to and who it is waiting on. It was built from that spreadsheet at the end of July, so the status on a row is the position that application had reached then. Two things on the row are live rather than frozen: when anyone was last in touch, and who it is waiting on. Both are read fresh every hour from the exemptions mailbox and the Sodalis note log, so a row can honestly show a status from July beside an email from this morning. Documents and notes accumulate on a row from here, as the work is done in the system rather than beside it.

The applicant's form is the other half. Each applicant gets a private link, fills the form in their own time, uploads what is asked for and submits.

Both are the real production system, running against the real 2026 backlog, plus our practice rows.

What has changed since the demo

The first four came out of the notes you gave in that meeting.

• HEIC images (from an iPhone) now open. Nathan hit this live: a member sent a photo his machine would not display without a plugin. Those are now converted the moment they are uploaded, so they open like any other image.
• Every column heading explains itself. Rest your pointer on one and it tells you, in a sentence, what the column is for.
• A document opens in a reader over the queue rather than taking over the screen, with a control inside it to send the document to its own tab, and a panel closes with the chevron in its header or the button that opened it.
• An applicant can remove a document you have not yet accepted or rejected, so an upload sent by mistake does not have to be worked around.
• The queue now shows when anyone was last in touch. A new column reads how long it has been since the last email in either direction, or the last note logged against that member in Sodalis, whichever is more recent. Waiting on reads the same traffic, so whose move it is comes from what actually happened rather than from the status alone.
• You can read what an applicant wrote. Where someone has submitted through their link, the Form column opens their answers underneath the row, section by section, as they typed them. Until this week the queue could tell you a form had arrived but not what was in it, which left the accept and reject buttons asking you to rule on a form you had no way of reading.

Practice rows, and real members

A row is a practice row if its name begins SANDBOX. Every other row is a real member's application. The practice rows are there so that you can experiment and verify the system without changing any real records.

What does not fully undo

Statuses can be reassigned, within the moves the system allows: you can switch an application from ‘pending exam’ to ‘pending reference’ and back, and almost anything can return to ‘submitted’. 'Rejected' is the strict one, and it takes two moves to come back from: rejected goes only to appeal, and appeal to final review.

Three things are kept in the record permanently:

• Accepting or rejecting a document. You can correct it, and the correction is recorded alongside the original rather than replacing it, because this is the record that has to stand behind a decision. The practice licence dashboard treats its own document decisions the same way.
• Accepting or rejecting the form as a whole, with the Accept form and Reject form buttons inside the Docs panel. That is a separate decision from the one you make on each document, and it is kept the same way.
• The trail of status changes. The status itself you can move as often as you need to; each move is added to the history rather than replacing what was there before.

Sending someone a form link

Nothing is emailed on your behalf: you are given a link to copy and send. The Link column reads Mint link when nobody holds one, Re-issue when somebody does, and a greyed-out unavailable once an application has been submitted, completed, withdrawn, rejected or sent to appeal. Re-issuing cancels the previous link for that applicant.

No real applicant has been sent a link yet, so every real row in Active reads Mint link, and no real application has documents on it to open.

Adding someone who is not in the queue

Mint application link sits in the controls bar at the top of the queue. It takes a membership number and a name, adds that applicant to the queue and makes their form link in one go, which is what you need for someone who is not on the list yet.

It will not reach anybody who is already there: if that member has a live application it refuses. The membership number is the part to be careful with, because it is not checked against Sodalis. A number typed wrong makes an application against the wrong member, or against nobody, and that row cannot be tidied away afterwards: it can be withdrawn, but it stays in the history.

It is also how you make yourself another practice applicant, which is worth doing: one applicant is one run through the form, and there are more paths through it than one person can take. Use a membership number between 999964 and 999998, and begin the name with SANDBOX so it is obvious to everyone what the row is. Then work the qualifications route on one, work experience on another, and whatever else you want to see the form do.

The first fifteen minutes

Start on the queue itself.

1. Open the queue with the link in Section 2. It opens on Active, which is every application still in play.
2. Rest your pointer on each column heading in turn and read what it says.
3. Work along the filters at the top: Not Contacted, Pending Ref, Pending Exam, Final Review and the rest.
4. Search for a name or a membership number. Note that searching hides rows but never renumbers them, so an applicant keeps their place in the queue.
5. Try clicking on things. The applicant's name is a link out to their record in Sodalis, in a new tab. The buttons in the Notes column open the dashboard's note thread for that applicant (not Sodalis comments). Docs and Background each open their own panel underneath the row, holding the documents on the application and the background checks. Docs reads as a dash until an applicant has uploaded something.
6. Read Last contact and Waiting on together. The first is how long since anyone last spoke to that applicant, counting email in either direction and notes logged in Sodalis; rest your pointer on it and it spells out both. The second is whose move it is, taken from that same traffic. On the SANDBOX rows, both will be blank, a dash and a faded chip, because nobody has ever emailed these fictional applicants.
7. Inside the documents panel, the name of a document opens it in a reader over the queue, and the arrow beside it downloads a copy. In the last column, Mint link opens a panel where a form link is made or re-issued: nothing is created until you press the button inside that panel.
8. Click a status. It shows you where that application is allowed to move next. Opening the menu changes nothing, so this is safe to do anywhere.
9. Open somebody's answers. The Form column becomes a button only on a row where the applicant has actually submitted through their link, so most rows will not offer it and no real 2026 row does yet. Two practice rows do: SANDBOX Ava Sterling (999950) and SANDBOX Bruno Achebe (999951), who came by the two different routes, so their answers do not read alike. A question left blank shows as not answered rather than vanishing, so a blank can be told from a question that was never put. Reading records nothing.

How new applicants will reach the form

Today someone applying for exemptions pays the application fee on the ICB website and is set up in Sodalis straight away. A welcome email follows automatically, listing what they need to send and pointing them at the current Microsoft Forms application form.

The intention is that the same email points them at this new form instead, with a link that is theirs alone. They can then start, stop and come back without losing their answers, and their documents arrive attached to their own record rather than as email attachments for someone to match up afterwards. The list you are testing would fill itself, in the order people pay, with no re-typing at either end.

That is a small change to make, but it is a change to an automatic outbound email, and hasn't happened yet.

Until then

New applicants are put onto this list rather than arriving on it. A fresh export of the tracking spreadsheet can be loaded in whenever Anthony has one ready. It only adds people it has not seen before, and it will not overwrite anything you have changed here.

One thing to expect, because it will look like a fault: the statuses you see are where each applicant stood on 29 July, the date of the export the list was built from.

The status is the only part that is frozen. Last Contact and Waiting On are read fresh from the mailbox and the Sodalis notes, so you will see recent dates sitting beside July statuses. That combination is correct rather than contradictory, and it is often the useful bit: it is how a row that has quietly gone cold tells you so.

Not built yet

These three are known gaps, on the roadmap.

• Referees filling in a form by link, in the way applicants now do, rather than by email attachment.
• A list of accepted qualifications to choose from, instead of a box the applicant types into.
• Reporting and export, by period and by team member.

Anything else you find is fair game, including things that work but feel wrong.

Sending your notes back

Reply to the email this came with. A screenshot is welcome wherever possible.

Where a note is about a particular application, the membership number and what you expected to see are the two things that make it actionable. “999958 said pending exam and I expected pending reference” is enough to find and fix.