A buyer needs the supplier record to place an order. Name, address, payment terms, the category the supplier sells in. The buyer does not need the IBAN. The payroll clerk needs the employee record, and the planner who books shifts from the same entity does not need the salary on it.
Most master data tools, Microsoft MDS included, make you decide per entity. Either the role sees the supplier or it does not. So the bank account ends up readable by everyone in purchasing, because purchasing has to read the supplier. Or someone splits the entity in two, Supplier and Supplier Bank Details, and the model now carries a join that exists only to get around a permission screen.
I don't like either answer. The first is how invoice redirection fraud finds its insider: more people can read payment details than anyone would sign off on if asked. The second pushes a security decision into the data model, where it outlives the reason for it by years.
One column, one role, set to None
Since version 1.2026.9.29 a column in Primentra has four settings per role: Inherit, None, Read and Write. None means the role does not see the column. The entity can grant full create, read, update and delete, and the column stays hidden anyway. You set it on the Roles & Permissions screen, under the entity it belongs to.
Inherit and None look alike in a dropdown and mean opposite things. Inherit has no opinion: the column follows whatever the entity gives. None is a stored refusal, and it beats the entity. Code and Name cannot be set to None, because a row nobody can identify is a row nobody can work with.
Hiding it in the grid is the easy part
Taking a column off the screen is the small job. The value also leaves the database through every other route you can read from, and each route is separate code that has to remember the rule. We learned this the unpleasant way. The first version hid the column in the grid, while the export, the REST API, global search and the row audit panel still handed it to anyone with read access on the entity. The fix went out in the same release, and it is why this list exists:
The audit history is the one people forget. A hidden IBAN that shows up in the history as an old value and a new value is not hidden. Search has the same problem: if typing half an account number finds the supplier, the search just told you how the number starts.
Writes are refused too. A grid save, bulk edit, file import, REST call or approval request that touches the column gets No access to column "IBAN". and nothing is written. If the hidden column is required, that role cannot create a new row, and the message says why instead of failing on a field the user cannot see.
The trap: two roles
Permissions in Primentra add up. When a user has several roles, the highest level wins, column by column. That is the right default for almost everything, and here it catches people out.
Anna is in Purchasing, which sets IBAN to None. She is also in Reporting, which reads the supplier entity and says nothing about the column. Reporting gives her Read. Read beats None. Anna sees the IBAN.
So hiding a column means checking every role a person holds, not just the one you edited. The permissions report shows the combined result per user, and Preview As opens the grid exactly as that user gets it. Using both as evidence for an auditor is the subject of the auditor doesn't ask who changed the record, they ask who still can.
Where hiding stops
The Primentra application enforces None, for Primentra users. It does not reach routes with no Primentra user behind them. A system loading through the staging tables writes every column. An integration view returns the columns it was built with, whoever queries it. And anyone with a SQL login reads the table directly.
I would rather you read that here than in a pen test report. If the column must also stay out of downstream systems, leave it out of the integration view and be strict about who gets a SQL login. Administrators see every column as well, so a None does nothing for them.
Common questions
Can I hide one column of an entity from a role?
Yes. Set it to None for that role. It disappears from the grid, filters, exports, search, the REST API, the row history and approval diffs, and a write to it is refused by name. Code and Name cannot be hidden. Administrators see everything.
What if a user has two roles and only one hides the column?
The highest level wins, so the user sees it. To hide a column, no role of that user may grant it. The permissions report and Preview As show the combined result.
Does it protect the column from SQL and integration views?
No. The application enforces it. Staging, integration views and a direct SQL login all go around it. Keep the column out of the view and be careful with SQL logins.
If you have a column in mind and a role that should not see it, set it up in the trial and open Preview As on that role. You get the grid that role gets, and you can check for yourself whether the column is gone.