Who gets to see the margin?

Every staffing firm draws the same line eventually. Recruiters should see enough to do the work. Not everyone should see what the firm makes on each placement.

The reasons are ordinary and good. Rates get discussed in a pub. A recruiter who knows the spread on every desk has a very different conversation when a competitor calls them. And some client contracts say plainly that commercial terms stay inside a named group of people.

So firms set permissions. Then most of them stop one step too early.

Hidden and absent are not the same thing

There are two ways to keep a number away from somebody.

You can leave the column out of the page. The data arrives at the browser, and the interface chooses not to draw it. This is the common implementation because it is easy — one flag, one condition, done.

Or you can never send it. The request comes in, the system works out who is asking, and the financial fields are stripped before the response leaves.

To a recruiter using the product, these look identical. To anyone who opens developer tools, or reads a cached response, or exports a page, they are not remotely the same. The first is a curtain. The second is a wall.

You do not need to be worried about malicious staff for this to matter. You need one curious person, one screenshot in a group chat, and one client who asks how their commercial terms ended up being general knowledge.

The question that gets a real answer

Do not ask a vendor “can I restrict who sees margin?” Everyone says yes.

Ask: “is the data still in the response?”

The answer will be immediate and confident, or it will be a pause. Both are informative. If they are proud of it, they will offer to show you — open a browser, sign in as a recruiter, look at what actually comes back.

Then check the second door

Permissions usually get tested on the screens people are meant to use. The gap is what happens when someone goes somewhere they were not invited.

Type the URL of a page your role should not have. A well-built system takes you somewhere sensible. A less careful one shows a blocked page — which at least means the route was checked. The bad outcome is the page loading with the data already on it and a friendly message on top.

Same test for exports. A CSV that ignores role scoping is the most common leak in this category, because export code is usually written once and rarely re-audited.

Draw the line once, in one place

The other failure is subtler: permissions defined in three places that disagree. The nav allows one thing, the API another, the export a third. Nobody is wrong on purpose — the rules were just written at different times by different people.

Ask where the rule lives. If the answer names one place, the system was designed. If it names several, you are going to discover the disagreements yourself, in production, on the day a client asks.