Three layers, and why the third one matters
Role-based access gets you most of the way. The last part — this person may see the part but not its cost — is what decides whether search can be index-partitioned, and it is why Manufacturing PLM filters at query time.
Three layers, in order
Roles. Nine verbs across sixteen resources, granted to ten roles. Read, create, edit, release, approve, delete, configure, administer, export — against parts, structures, documents, changes, suppliers and the rest. Coarse, comprehensible, and enough for most of what an organisation needs.
Attribute rules. Conditions over the object rather than the type: this role may edit parts in this classification, or approve changes below a cost threshold, or read documents belonging to a programme they are assigned to. This is where an organisation's actual policy lives.
Field-level control. A person may see a part and not its cost. That is the layer everyone leaves until last, and it is the one with the largest architectural consequence — because a rule whose unit is the field cannot be expressed as membership of a partition whose unit is the document.
The mechanism: why filtering happens at query time
Search could partition its index by permission at write time. Manufacturing PLM does not, and the field layer is the deciding reason.
Attribute-level access control does not partition at all. You cannot put a part in the index-partition for people-who-may-see-cost and also in the one for people-who-may-not, because it is one document with a field some readers get and others do not. Query-time filtering handles it; partitioning cannot.
The second reason is ordinary but expensive: a permission change under partitioning means re-indexing. Somebody joins a programme on Tuesday and search has to be rebuilt before they can find anything, so in practice permissions and search drift apart and nobody notices which direction.
Results, totals, facet counts and pagination all derive from one clause. A total of twenty-nine above twenty-six visible rows announces three objects as effectively as listing them, so they are not permitted to come from different queries.
The failure it prevents
A contractor is granted access to one programme. They search for a competitor's product name — out of curiosity, or because it came up in a meeting — and correctly get no results. Beside the empty list, the facet panel reads Programme: 14.
Nothing was disclosed in the ordinary sense. No part number, no document, no drawing. But the existence of fourteen objects under a programme they cannot open is now known, and in an acquisition, a customer-confidential build or anything under NDA, existence is frequently the sensitive part.
The same class of leak hides in autocomplete endpoints, export jobs running outside a request, and aggregate reports over tables the ordinary screens never touch. None of them look like security surfaces during review, which is why the control has to sit below all of them rather than in each.
How it meets the rest of the product
Administrators have no silent bypass. An administrator who needs into a restricted programme grants themselves access, and the grant is an audit row. That is the difference between an access control story that survives a review and one that ends with somebody saying nobody can tell.
Agents inherit the acting user's permissions in full, including field-level rules. An agent asked about a restricted programme by somebody without access returns the same nothing that person would get from search, and the refusal is shaped so it does not confirm the object exists.
External supplier sessions narrow a second time on top of everything above, to the objects explicitly shared with their organisation. That is a different mechanism rather than a strict role, because an external organisation is a different kind of principal.
Identity comes from SSO with SCIM provisioning, so joiners and leavers run through the process you already have rather than a separate user list somebody forgets to prune.
How it meets your ERP
Field-level control and field ownership are different things that interact. Cost is ERP-mastered, so nobody can edit it in Manufacturing PLM regardless of role — that is ownership. Whether a given person can *see* it is access control, and the two rules compose rather than overriding one another.
Connector runs establish the same tenant context a user request does, so the predicate applies to sync work. Background jobs are where access control usually leaks, because a nightly job typically holds broad credentials and iterates across everything it can reach.
API tokens are scoped per tenant and cannot exceed the permissions of the identity behind them, including field rules. A token whose identity may not see cost receives responses without the field rather than nulls that quietly imply the value is absent.
Where the boundary is
This is authorisation, not deployment isolation. Logical separation on shared infrastructure is what Manufacturing PLM offers; single-tenant, on-premise and ITAR-segregated deployment are out of scope as a permanent architectural decision rather than a roadmap item.
Nor does access control prevent somebody with legitimate permissions from doing something harmful. That is what permission tiers, approvals and the hash-chained audit trail are for — and an organisation that grants broadly and audits nothing has chosen a different control, not a weaker version of this one.
Facts
| Layer 1 | Roles — 9 verbs across 16 resources, 10 roles |
| Layer 2 | Attribute rules — conditions over the object |
| Layer 3 | Field-level — see the part, not its cost |
| Why query-time | Field rules cannot be expressed as an index partition |
| Consistency | Rows, totals, facets and paging from one clause |
| Administrators | No silent bypass — elevation is an audit row |
| Agents | Inherit the acting user's rules, field level included |
| Not offered | Single-tenant · on-premise · ITAR segregation |
Frequently asked
Why not partition the search index by permission?
Because field-level rules cannot be partitioned. A part cannot sit in both the may-see-cost partition and the may-not partition — it is one document with a field some readers get. Query-time filtering handles that; index partitioning has no way to express it.
What is the practical cost of partitioning?
A permission change means re-indexing. Somebody joins a programme on Tuesday and the index has to be rebuilt before they can find anything, so in practice permissions and search drift apart — and nobody can easily tell which of the two is currently correct.
Can facet counts reveal hidden objects?
No. Results, totals, facet counts and pagination all derive from one shared clause, so a facet reading fourteen beside an empty result list cannot occur. Existence is frequently the sensitive part, particularly during acquisitions and on customer-confidential builds under NDA.
Do administrators see everything?
Not silently. An administrator who needs access to a restricted programme grants it to themselves, and the grant is an audit row. A super-user bypass is convenient right up to the compliance review where somebody asks who read a file and nobody can tell.
How do agents interact with these rules?
They inherit the acting user's permissions in full, including field-level ones. An agent asked about a restricted programme by somebody without access returns the same nothing that person gets from search, with the refusal shaped so it does not confirm anything exists.
How is this different from field ownership?
They compose rather than compete. Cost is ERP-mastered so nobody can edit it regardless of role — that is ownership. Whether a given person can see it at all is access control. A field can be visible and uneditable, or editable by role and owned elsewhere.
Does it stop insiders doing harm?
No, and nothing framed as access control ever does. Permission tiers, approvals and the hash-chained audit trail are what address that instead. An organisation that grants broadly and audits nothing has chosen a different control rather than a weaker version of this one.