A Blacklist That Works and a Preference That Does Not
Blacklisting a supplier here does five things at once, refuses to be undone by accident, and blocks them from applying again through the public form. Marking one preferred does nothing at all. Two flags on the same record, and only one of them is a control.
Open a supplier record and you will find two switches next to each other. One of them is among the better-built controls in the product. The other is a label. Nothing on the screen distinguishes them.
What blacklisting actually does
Five things, in one action.
-
Sets the blacklist flag
The obvious part, and the least interesting.
-
Deactivates the vendor
This is what makes it bite. An inactive vendor drops out of quotation selection, so blacklisting is not a note on a record — it removes the supplier from the buying process.
-
Records who, when and why
The actor, the timestamp and a reason of up to five hundred characters. A blacklist without a reason is an argument waiting to happen, usually eighteen months later with nobody who remembers.
-
Refuses reactivation while the blacklist stands
Somebody trying to switch the vendor back on is told explicitly to remove the blacklist first. The two states cannot get out of step.
-
Blocks re-application through the public form
A prequalification application from that email address, for your organisation, is refused. Which closes the obvious route back in — reapplying as a new supplier.
And there is a sixth thing that is a decision rather than an action: removing the blacklist leaves the vendor inactive. The message says so in words. Un-blacklisting is not readmission; somebody still has to decide to activate them, as a separate act.
Removing a blacklist and letting somebody trade again are two different decisions, and the product refuses to collapse them into one.
That is a small design choice with a large governance consequence, and it is the sort of thing that is only ever got right on purpose.
What "preferred" does
On a supplier record: nothing.
It can be set. It is copied across when a prequalified application becomes a vendor. It is returned by the API. It does not order suppliers in any selection list, it does not default an invitation, it does not weight a quote comparison, and no rule anywhere reads it.
It does do one real thing, and it is worth knowing because it is easy to mistake for the general case: on a prequalification application, being preferred pushes the application to the top of the review queue. That is a genuine behaviour, in one screen, before the supplier is a supplier. Once they are, the flag goes quiet.
| Flag | On an application | On a vendor |
|---|---|---|
| Blacklisted | Blocks a new application from that email | Deactivates, records reason and actor, refuses reactivation |
| Preferred | Sorts the application to the top of the review queue | Nothing |
| Active | Not applicable | Controls whether they appear in quotation selection |
Why the difference matters in a multi-tier supply base
Malaysian manufacturing and distribution tends to run a wide supplier base with an explicit hierarchy inside it — a small set of qualified primaries, a longer tail of alternates, and a set of suppliers who are approved for one category and not another.
The instinct is to encode that hierarchy in the preferred flag, and the flag will happily accept it. What it will not do is act on it. So the buyer who ought to be steered towards the primary supplier is steered by nothing, and the hierarchy exists in a column that no process consults.
The working alternative is blunt and effective: the active flag is your real hierarchy. A supplier who should not be receiving routine business is inactive, and activated deliberately when they are needed. That is a heavier action than marking somebody non-preferred, which is precisely why it works.
Making preference mean something
This is one of the smaller items we publish about, because the field, the toggle and the API already exist. What is missing is a consumer.
Preferred suppliers first in selection
The least intrusive version and probably the right one: order the list, do not restrict it. A buyer who wants an alternate can still choose one.
Preference per category
The version people actually want, and materially larger, because it needs a relationship between a supplier and a category rather than a flag on a record.
A reason and an owner on the flag
Blacklisting records why and who. Preference records neither, so nobody can say when it was granted or on what basis.
No dates on a public page. If steering buyers towards a qualified primary is a governance requirement, describe it and we will scope it in writing before you commit.
Scope supplier tieringThree questions about supplier flags
Blacklist a supplier in front of me. What changes?
A good answer sounds like
A list of side effects, demonstrated.
What it actually means
A blacklist that only sets a flag is a note. Ask what stops somebody buying from them tomorrow.
Can a blacklisted supplier reapply through your public form?
A good answer sounds like
No, blocked on the email.
What it actually means
The obvious way back in, and the one most systems leave open.
What does marking a supplier preferred change?
A good answer sounds like
A named behaviour.
What it actually means
Ours changes nothing on a vendor. A flag with no consumer is the most common form of decorative feature in this category.
Our position
Use blacklisting freely — it is a real control with a recorded reason and no accidental route back in. Do not build a supplier hierarchy on the preferred flag, because nothing reads it. If you need buyers steered, use the active flag as your tier: routine suppliers active, everybody else inactive until somebody decides otherwise.
What AWRA OpsHub does today
- Blacklisting that deactivates the vendor, stores a reason of up to five hundred characters, and records the actor and the time.
- A refusal to reactivate a vendor while the blacklist stands, with an explicit message.
- Removal of a blacklist leaving the vendor inactive, so readmission is a separate decision.
- A refusal of public prequalification applications from a blacklisted email, per organisation.
- The same refusals mirrored on the API.
- An active flag that genuinely controls whether a supplier appears in quotation selection.
What it does not do
- Any behaviour behind the preferred flag on a vendor — no ordering, no default, no weighting, no rule.
- A reason or an actor on the preferred flag, unlike the blacklist.
- Preference or approval per category, so a supplier approved for one thing is approved for everything.
- Any refusal to order from a supplier whose qualification has lapsed beyond the automatic deactivation that already handles it.
Not ours, by choice
- The preferred flag does do something on a prequalification application — it sorts the review queue. That is real, and it is not the same as behaving on a vendor.
- Using the active flag as a tiering mechanism is blunt and it works. It is also the sort of thing that needs writing down, or the next administrator will activate everybody.
- Nothing here is Malaysian. It is what a flag with no consumer does; a multi-tier supply base is simply where you notice.
Write down what your supplier tiers actually mean
If the tiers are real, they need a mechanism, and today that mechanism is the active flag plus a policy. We will help you decide which suppliers should be switched off by default.
Set the tiersFrequently asked questions
Does blacklisting affect orders already placed?
The vendor becomes inactive and unselectable for new quotations. Existing orders are not cancelled, and receipts and payments against them continue to behave normally — which is usually right, since the goods may already be on their way, and cancelling is a commercial decision rather than a system one.
Can I blacklist a supplier for one category only?
No. Both the blacklist and the active flag are organisation-wide for that supplier. A supplier who is unacceptable for one category and fine for another has to be managed by policy rather than by the system.
Should I use preferred at all?
As documentation, yes — it is a place to record a judgement, and the API returns it, so an integration could act on it even though the product does not. Just do not build a process that assumes a buyer will be steered by it, because they will not be.
