When you invite a vendor into your workspace, you are not creating a limited member of your team. You are opening a separate door onto 24 routes, every one of which re-checks that the record in front of it belongs to that supplier before it renders a line of it. There is no role to misconfigure, because a supplier has no role — the boundary is structural, and this page is about exactly where it runs.
The usual way to build a supplier portal is to create a stripped-down user with a “Vendor” role, and it works right up until somebody edits that role on a Thursday. Suppliers here authenticate against a separate guard entirely. They are not users, they hold none of the 258 permissions in the role catalogue, and no change an administrator makes to a role can widen what a supplier sees.
Every supplier-facing lookup filters on that supplier's own id and fails to find anything else. Change the number in the address bar and you get a not-found — not a permission error, because as far as the query is concerned the record does not exist. Hiding a row in the template and fetching it anyway is the version of this that passes a screenshot review and fails a penetration test.
Suppliers can download the file on their own quotation. That route is the single documented exception in our access-control map, because it runs on the supplier guard and so has no role permission to declare. The controller earns it a different way: it matches the tenant and the quotation's own supplier id, so a supplier can only ever reach their own document.
Quote submission, PO acceptance, rejection, closure and shipping updates each sit behind a throttle of their own, on top of the throttle applied to the whole portal. A supplier integration gone wrong is a nuisance in your procurement queue rather than an outage.
This is the line that matters, and most portals put it in the wrong place. A supplier who can mark an order delivered can close out your receiving obligation from their own office, and the first person to discover the discrepancy is a storekeeper with a clipboard and no leverage. So the portal splits every fact into two kinds: things the supplier is the authority on, and things only your own people can assert.
The supplier decides these
Only your side decides these
The shipping control is a two-value field on purpose. A supplier sets it to in-transit and the system issues a tracking reference; move it back and the reference is withdrawn. Once your own receiving or a cancellation has decided the order, the control locks entirely and says why — so a supplier cannot reopen a shipping conversation about goods you have already booked in.
This is a real order as both sides see it. The supplier and the buyer are looking at one record, not at two copies being reconciled by email — but each field still has exactly one owner, and neither side can write the other's.
Buyer wrote this
PO-2026-0912
Raised against the winning quotation, with the sourcing decision still attached to it.
Supplier wrote this
Vendor accepted
The commitment. Until this exists, the buyer has an order and no promise against it.
Supplier wrote this
in_transit
It has left them. A tracking reference was issued when they said so.
Buyer wrote this
Received · 84 of 90
Counted at the bay by your storekeeper. The six-unit shortfall is now a conversation with evidence.
A buyer setting up a supplier's credentials and reading them down the phone is the ordinary way this goes wrong: the buyer has now held the supplier's password, and every later action from that login is arguable. The first sign-in is built to make that impossible.
Name, contact, email. The record is the same one your purchase orders already point at, so a portal login is a capability added to a supplier you already trade with rather than a second, parallel supplier record to keep in step.
An account that has never had a password set, or that is flagged to change one, is signed straight back out at the door and emailed a link instead. The attempt is written to the security log with its reason, so an administrator can see the handover happened without ever seeing the credential.
The supplier's sign-in reads the multi-factor policy set on your workspace. If you require it, they are challenged before a session exists; if you recommend it, they get the same reminder cadence your own staff get, with the same snooze. A supplier who can accept a six-figure order is a person signing into your procurement process, and your policy is the one that should govern it.
Supplier sessions run through the same timeout, the same audit logging and the same request profiling as your internal team's. There is no quieter, older code path for the external door — which is usually where the quieter, older code path is.
Every organisation has two or three things it needs from a supplier that no product ships with: a batch reference, a driver's name, a compliance certificate number, the gate the lorry should use. Custom fields defined on your purchase orders appear on the supplier's form, are validated by your rules when they submit, and are saved against the same record your own team reads.
A field on the supplier's acceptance form gets answered while the supplier is deciding whether to accept. The same question asked afterwards, by email, gets answered by whoever reads the email first — and usually a week later, into a thread nobody attaches to the order.
The fields apply to acceptance, rejection, closure and shipping updates alike, so you can require a reason on a rejection without requiring one on an acceptance.
The supplier's submission is validated against the field definitions held in your workspace before anything is written. A required field is required; a field with a format has that format enforced. The supplier is not trusted to have filled the form in correctly, which is the correct posture towards any input arriving from another organisation.
Custom fields on the portal are the same mechanism used across employees, tickets, projects, tasks and expenses — one definition surface, not a per-module reimplementation.
Access-control claims are the easiest thing in software to write and the hardest to verify from the outside, which is why so many of them are written. These are ours, in the order you would check them, with what you should see.
Give both a portal login. You now have two doors into one workspace and a record behind each of them, which is the only arrangement that tests anything.
Open their purchase order, then change the identifier in the URL to the second supplier's. You should get a not-found, not a forbidden and not a blank page with the other supplier's total still in the tab title.
Accept the order, then open the shipping control. There are two values in it and delivered is not one of them. Then book the goods in from the buyer's side and go back — the control is now locked and tells you why.
The close is refused with the reason. Mark the order paid on your own ledger, go back, and the same button now works — because the condition was a fact on your side all along.
Then sign the supplier out and back in. They are challenged, from your policy, on an account you did not configure — and their session times out on your timeout.
Stock levels, your other suppliers, prices you paid last quarter, the names of your staff. There is no navigation to them and no route that serves them, which is a duller answer than a permission matrix and a considerably stronger one.
What AWRA OpsHub does today
More we can add to your workspace
Where we point you to a specialist
Everything in the middle column is scoped work on a portal that already has the guard, the scoping, the throttles and the custom-field layer to hang it on. Tell us which row your suppliers keep asking for.
The supplier's side of the work: reviewing an RFQ, submitting a quote, answering an order.
What the buyer learns from all of it: response times, delivery reliability, open issues.
Before any of this: a public application, a review, and an approval that creates the vendor.
The buyer's side of the request the supplier is answering, and how quotes are compared.
The receiving event the supplier cannot write, and what happens when the count is short.
The permission model your own team is gated by, and which suppliers are deliberately outside.
Help Center
Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.
