A Public Form With Your Name in the URL
Suppliers apply to you through a public page addressed by your organisation's own slug, with no account and no login. Everything after that — the tracking link, the document requests, the eventual portal account — follows from decisions in that one route.
The awkward part of supplier onboarding is that the supplier does not have an account yet, and giving one to everybody who fills in a form is how you acquire a directory of strangers.
Our take
The design decision that makes this work is that no account exists until somebody in your organisation decides one should. An applicant reaches a public page, submits a pack, and is given a signed link to their own application — not a login, not a password, not a row in your user table. A portal account is created later, when an approved application is converted into a supplier record, which means the population of people who can sign in is exactly the population you have approved. The cost of that choice is that everything before approval has to work without authentication, and the interesting engineering here is all in how that is done safely: a slug that identifies you rather than them, a signed link with an expiry, and three separate defences against the fact that a public form is a public form.
The URL identifies you, not them
Your organisation has a public slug, and the application page lives at that slug. That is what tells the system whose supplier register an application belongs to, because there is nobody signed in to ask.
Two behaviours follow, and both are worth knowing before you print the link on anything.
-
A retired slug still works
Change your public slug and links carrying the old one keep resolving, then redirect to the current address. Without that, an organisation renaming itself would break its own application link — including the one printed in a tender document eighteen months ago.
-
A closed register is a closed door
Your organisation controls whether it is accepting applications. When it is not, the page returns a plain not-found rather than a message explaining that you exist but are closed. That is deliberate: a page that says "this organisation is not currently accepting applications" is a page that confirms which organisations exist on the platform.
What the pack asks for
Three things are required — a company name, an email address and a phone number — plus one document: proof of incorporation. Everything else is optional and can be supplied or requested later.
| Field group | Required? | Notes |
|---|---|---|
| Company name, email, phone | Yes | The minimum needed to have a conversation. |
| Contact person, registration number, tax identifier, years in business, category, address, county | No | Asked for, not insisted on — an incomplete pack is better than an abandoned one. |
| Incorporation document | Yes | Up to eight megabytes, as a PDF or an image. |
| Tax compliance, bank details, portfolio | No | Same limits, with the portfolio also accepting word processor files. |
| Your own custom fields | As you define them | The same field customisation engine used across the product applies to this public form. |
One required document rather than four
It is tempting to make the whole pack mandatory, and it is the wrong instinct for a form a stranger meets cold. An application that arrives with one document and a phone number is a conversation you can have; a form that refuses to submit without four documents is a supplier who gives up and calls somebody else. The rest is requested during review, from a person, with a reason — which is also when a supplier is most willing to supply it.
Three defences, and the one that says nothing
A public form that accepts file uploads is an invitation, and it is defended three ways.
- A rate limit on submission, so volume is bounded regardless of anything else.
- A verification challenge, enforced only where your organisation has configured one — present it if you have it, and the form works without it if you have not.
- A hidden field and a timing check, which together catch automated submissions. This one behaves differently from the other two: on a hit, the response is the same success message a real applicant sees, and nothing is stored.
That last behaviour is deliberate and worth understanding. Telling an automated submitter that it was detected is telling it what to change. Accepting quietly and discarding gives it no signal at all, which is why the page a bot sees and the page a supplier sees are identical.
A refusal is feedback. Silence is not.
The blacklist reaches the front door
An application from an email address belonging to a supplier your organisation has blacklisted is refused, with a neutral message inviting them to get in touch if they believe it is an error. That is the right wording — it declines without explaining the criterion, which is both more polite and less useful to somebody testing which addresses are blocked.
A link instead of an account
On submission the applicant is emailed a signed link to their own application. It is valid for ninety days, and it is refreshed each time your reviewers ask them for more information. From it they can see the status of their application and upload whatever has been requested.
Two properties make this safe. The link is signed, so it cannot be constructed or altered — the signature is what proves the address came from you. And it expires, so a link forwarded to a colleague or left in an inbox does not grant access indefinitely.
There is a subtle piece of engineering behind it worth naming, because it is the sort of thing that breaks quietly. These pages have no signed-in user, so there is nothing to establish which organisation the request belongs to. The application is therefore looked up by its identifier explicitly, with the signature standing as the proof of authorisation, and the page is then rendered in the context of the organisation that owns it. When record lookups tightened so that an unidentified request returns nothing rather than everything, an implicit lookup here would have started returning not-found on every valid link — which is exactly the kind of failure that reads as an email problem for a fortnight.
From a form to a register that maintains itself
The application route, the tracking link and the conversion to a supplier record all work. What buyers ask for next is the part that keeps the register current after approval.
A renewal application
An existing supplier invited to refresh their pack before their qualification lapses, through the same public route and against their existing record.
Document expiry per document
A tax compliance certificate that expires on its own date rather than the whole qualification expiring together.
A category-driven pack
Different required documents for a caterer and a civil contractor, defined per category rather than one list for everybody.
We publish scope, not dates.
Scope supplier onboardingFive questions to ask about supplier onboarding
Does an applicant get an account?
A good answer sounds like
Not before approval.
What ours actually is
No account at all. A portal login is created only when an approved application is converted into a supplier record.
How does the form know which organisation it is for?
A good answer sounds like
Something in the URL.
What ours actually is
Your organisation's public slug, with retired slugs still resolving and redirecting to the current one.
How can a supplier check progress?
A good answer sounds like
A link, with an expiry.
What ours actually is
A signed link emailed on submission, valid for ninety days and refreshed whenever more information is requested.
What stops automated submissions?
A good answer sounds like
More than one thing.
What ours actually is
A rate limit, an optional verification challenge, and a hidden-field and timing trap that accepts silently and stores nothing.
Can a blacklisted supplier reapply?
A good answer sounds like
No, politely.
What ours actually is
The application is refused with a neutral message that does not explain the criterion.
What AWRA OpsHub does today
- A public application page addressed by your organisation's own slug, needing no account and no login from the applicant.
- Retired slugs still resolving and redirecting to the current address, so a link printed in a tender document survives a rename.
- A per-organisation switch for whether applications are being accepted, with a closed register returning a plain not-found rather than confirming the organisation exists.
- A pack requiring a company name, an email, a phone number and proof of incorporation, with tax, bank and portfolio documents optional.
- Your own custom fields on the public form, through the same field customisation engine used across the product.
- Three independent defences on submission: a rate limit, an optional verification challenge, and a hidden-field and timing trap that accepts silently and stores nothing.
- A blacklisted supplier's email refused at the front door with a neutral message.
- A signed tracking link emailed on submission, valid for ninety days, refreshed each time information is requested, letting the applicant see status and upload documents without an account.
- Notification to your administrators when an application arrives.
- A portal login created only on conversion of an approved application into a supplier record.
More we can add to your workspace
- A renewal application inviting an existing supplier to refresh their pack through the same route before their qualification lapses.
- An expiry date per document, so a tax certificate ages on its own timetable rather than with the whole qualification.
- A required document list per category, so a caterer and a civil contractor are asked for different things.
- A saved draft, letting an applicant return to a part-completed form rather than starting again.
- Applicant-visible reasons for a decline, where an organisation wants to give them.
- A duplicate check across applications, catching the same company applying twice under two email addresses.
Where we point you to a specialist
- We will not create a login for an unapproved applicant. The population of people who can sign into your workspace should be the population you have approved, and a form that mints accounts turns a public page into an account factory.
- We will keep a closed register returning a plain not-found rather than an explanation. A page confirming that an organisation exists but is not accepting applications is a directory of every organisation on the platform, available to anybody guessing slugs.
- Deciding which suppliers are acceptable is entirely yours, including the criteria and the wording of a refusal. We will hold the pack, run the workflow and record the decision; we will not publish a standard that implies who ought to qualify.
A renewal application through the same public route is the contained piece here, and it is the one that turns a supplier register from a snapshot taken at onboarding into something that stays current.
Put the link somewhere it will be found
The most common reason a prequalification register stays empty is that the address only exists in one person's email signature. It is a stable public URL and it survives a rename — put it on your website.
Talk through supplier onboardingFrequently asked questions
Do suppliers need an account to apply?
No. The application page is public and needs no login, and no account is created by submitting. A portal login appears only when an approved application is converted into a supplier record, which means everybody who can sign into your workspace is somebody you approved.
What happens if we change our public slug?
Links carrying the old slug keep working and redirect to the current address. That matters more than it sounds — an application link can end up in a tender document, on a printed poster or in a supplier's bookmarks, and an organisation renaming itself would otherwise break its own front door.
How does a supplier check on their application?
Through a signed link emailed to them on submission, valid for ninety days and refreshed each time your reviewers request more information. From it they can see the status and upload whatever has been asked for, without an account. The signature is what proves the link came from you, and the expiry is what stops a forwarded link granting access indefinitely.
What stops the form being spammed?
Three things working independently: a rate limit on submission, a verification challenge where your organisation has configured one, and a hidden field with a timing check. The third behaves differently from the other two — an automated submission gets the same success message a real applicant sees and nothing is stored, because telling a bot it was detected tells it what to change.
Can we require more documents than the one?
Not as required fields today — proof of incorporation is the only mandatory document, with tax, bank and portfolio optional. Your own custom fields can be added to the form through the same engine used elsewhere in the product. A required list that varies by supplier category is the item on the list above that most organisations want next.
Why does a closed register return a plain not-found?
Because a page that says "this organisation exists but is not accepting applications" turns slug-guessing into a directory of every organisation on the platform. A not-found reveals nothing about whether the slug corresponds to anybody, which is the correct answer to a request from a stranger.
