lit posture, applies them to every Records read and write, so a person reaches through the API exactly what your rules allow. Under the dark and shadow postures it serves your organization’s identity mapping and does not enforce the seat. It reads your sources when the person asks and keeps no copy of your staff list.
Where each answer comes from
For example, an agency that signs in with Microsoft Entra ID and keeps its book in AMS360 has its Entra sign-in, its AMS360 security groups and business units, and its HR directory read this way.
How your rules are applied
- Your identity provider signs the person in, and your server names them on the request.
- Nexio finds the person in your HR directory and your system of record. When your records do not settle who the person is, the person’s requests are refused until the match is confirmed. Your organization confirms it with its own live key or through its delegated access administrator, or Nexio does when you ask. Nexio does not guess.
- Nexio applies the mapping from your security groups and business-unit access to the platform’s roles, field classes and row scopes. The inputs are yours; Nexio holds the mapping. A group the mapping does not know grants nothing.
- The result bounds every read and write. A field the person’s role may not see is blanked, and a record outside their access does not exist for them. The details are on Authority and scope.
Changing access
Change access where your rules live: add the person to a security group, change their business-unit access, or update their HR record. Nothing needs to change on the Nexio side, unless you create or rename a security group: Nexio adds the group, or its new name, to the mapping, and until then it grants nothing. Some access has no home in your systems: a time-boxed exception for one workflow action, an assignment to one piece of work, or an added grant. Your organization sets these with its own live API key, or a person your organization has delegated as an access administrator sets them; Nexio sets them only when you ask. Each one carries a reason and is written to the audit log. An exception never widens the records a person may open.Seeing what a person will see
A preview of a person’s access, or of a change before it is made, shows the access before and after and stores nothing. Your organization runs it with its own live key or through its delegated access administrator, and Nexio runs one when you ask. The management routes for the posture, added grants, exceptions, assignments, match confirmations, previews and the access audit are provided to each customer as part of their integration reference, not on a public page. From your application, readGET /api/v1/records/status as the person. It reports the scope they are served at and answers the identity refusals as data, so you can explain them before the first read (see Preflight with the status read).
Audit
Every access change and every refused governed action is written to an append-only audit log. Your organization reads it with its own live key. See Security and compliance.Next
Authority and scope
Name the person, sign the claim, and handle every refusal.
Completeness and errors
Check a person’s scope before the first read.