A target restricts documents, and not your customer list — transcript

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This lesson is for whoever has been asked to make sure one branch cannot see another’s figures. In about thirteen minutes you will know exactly how far that goes, where it stops, and why the place it stops is not a fault you can configure your way out of.

Step 1 — Set the target, and know what you have written

After this step you will read the Permission Sets screen accurately. A permission set is scoped by choosing a target table — company, branch or location — and then one record of it. That choice is stored on the grant, alongside the permission code and whoever holds it. A grant with no target at all is unrestricted, which is right for an administrator and almost never right for anybody else. Across the live tenant estate this is a mechanism in real use rather than a curiosity: most tenants hold some grants pinned to a specific record, location and branch targets are the commonest, and nearly all grants are attached to roles rather than to individual logins.

Reference: Tenant Admin Applet — What the target actually does once you have set it

Step 2 — See it work on documents, which is where it bites

After this step you will know the case the mechanism was built for. When the server answers a request for documents — invoices, orders, receipts, stock takes — it puts your grant’s company, branch and location into the query itself and returns only the rows you are permitted. A document is visible if you are permitted at its company, at its branch, or at its delivery branch, which is the clause that lets a fulfilment team see what is being sent to them without seeing the branch’s other trade. This is a genuine server-side control. You can say so to an auditor, and it will survive being tested.

Reference: Tenant Admin Applet — What the target actually does once you have set it

Step 3 — Then watch it not happen on the customer list

After this step you will stop relying on the thing most people rely on. Ask the same server for customers, and it checks that you hold the read permission and then returns the whole tenant, whatever branch your grant names. Suppliers, items and price rows behave the same way. So a cashier scoped to one branch can still search up a customer who has only ever shopped four hundred kilometres away. That is not your configuration going wrong; there is no setting that changes it. If somebody has been told that branch scoping keeps the customer list apart, they have been told something that is not true, and it is better to find out here.

Reference: Teams and Permissions — Step 4: Scope each permission to a branch or company

Step 4 — Understand why it stops there, because the reason is useful

After this step you will predict which other screens behave which way. Narrowing a listing by target is not something the platform does to every query. The permission layer hands each endpoint the list of companies, branches and locations you are permitted, and it is the endpoint’s own query that has to use them — the code that does this says so in as many words. A handful of classes have taken the option, and the one carrying most of the business is the generic document. The rest have not. So the rule of thumb is: if what you are looking at is a document, expect scoping; if it is a master record, do not.

Reference: Tenant Admin Applet — What the target actually does once you have set it

Step 5 — Meet the symptom before your users do

After this step you will recognise the commonest access complaint on sight. Company, branch and location selectors are built from exactly these targets: the applet asks the server which permissions you hold and with which targets, and offers you those and nothing else. So a role scoped at branch level with nothing at company level opens a new document with an empty Company selector and cannot save anything. Worse, you will not be able to reproduce it, because holding tenant admin or tenant owner skips the whole check and shows you every company. Test as an ordinary member of the team, every time, and give every document-creating role a company target as well as a branch one.

Reference: Teams and Permissions — Step 4: Scope each permission to a branch or company

Step 6 — Design the boundary where the boundary holds

After this step you will have something you can defend. Put the confidentiality line at the document level, where the server enforces it, and treat the customer, supplier and item masters as visible to anyone who may read those masters at all. Keep the controls that genuinely are server-side and separately granted — being able to view a customer really does not let you export the customer list, and that one refusal happens on the server. And if a group truly needs two customer lists that cannot see each other, the answer is two tenants. It is a bigger answer than people want, and it is the true one.

Reference: Teams and Permissions — Step 3: Split view, edit and export

How the steps fit together

    flowchart TD
  s1["Step 1 — Set the target, and know what you have written"]
  s2["Step 2 — See it work on documents, which is where it bites"]
  s3["Step 3 — Then watch it not happen on the customer list"]
  s4["Step 4 — Understand why it stops there, because the reason is useful"]
  s5["Step 5 — Meet the symptom before your users do"]
  s6["Step 6 — Design the boundary where the boundary holds"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6
  

Check yourself

Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.

Next: Everything hangs off a role · Back to the series · Play this as a presentation