Workshop 9 (optional): Access Control

This workshop decides who may see which records in the knowledge graph. By default every signed-in user can read everything that was ingested. That is right for most firms, most of the time. It is wrong when the graph holds contracts under confidentiality terms, HR data, work behind an ethical wall, or a client that insists on restricted access. Access control filters every graph query to the records the person is entitled to, so the same question returns different answers for different people. Run this workshop only when you need it. It matters for accuracy because a policy with a gap does not raise an error. It quietly hides records, and a golden question that passed in validation starts failing for real users.

​

At a glance

​

Before the workshop

FFE and Experio SMEs:

• Read Graph Access Control end to end. The setup order and the traps on that page are what you will follow after the workshop.
• List every entity type in the graph, not only the ones you expect to restrict. Include Document and any other labels the pipeline writes. A label with no baseline row is treated as private, so you need the full list.
• For each candidate private type, check that a relationship connects it to a person, directly or through something the person already reaches. Open Model & Define > Ontology and write the relationship names down exactly.
• Prepare 3–5 test users in Administer > User Profile Management, one per level you expect to test (see the persona table below). Each test user must exist as a person in the graph with real work relationships.

Client homework:

• The data owner brings the rule in plain words: “Only Legal and the people on the engagement may see a contract.”
• The super user brings the list of pilot users, their roles, and who they report to.
• IT confirms whether any rule comes from a contract or regulation. Those rules need the sponsor’s sign-off.

​

Agenda

​

Running the workshop

​

1. Classify every entity type

Walk the entity type list one row at a time. Ask:

• “If any employee could see every record of this type, would anyone object?” If no, mark it public read.
• “Who is allowed to see it, in your words?” Write the answer down verbatim. It becomes the grant rule.
• “Is there anything attached to it that is just as sensitive?” Obligations inside a contract, for example. Those types must be private too, or the detail leaks through them.

Keep the private list short. Every private type hides some records from everyone, because some records have no path to any person. The admin guide shows real numbers for this under What making a label private actually costs.

​

2. Decide how a person reaches a private record

Access in Experio starts from work. A grant rule names a relationship that attaches a person to the graph, such as WORKS_ON_PROJECT. From what the person holds, propagation rules extend access one step at a time: “if you hold this, you may also read that, over this relationship”. Roll-up axes describe containment, where holding a parent gives you what is filed under it. Ask the room:

• “How does a person earn access? By being staffed on the work? By being in a department?”
• “If you can see the project, should you see the contract that governs it? All contracts with that client, or only this one?”
• “If you can see a contract, should you also see its amendments and obligations?”
• “Is there anyone who needs access but is never staffed on the work (Legal, Finance, leadership)? How do we connect them?”

When someone needs access without being staffed, you have two honest options. Either load a relationship that records their responsibility (from a small structured file the data owner maintains), or rely on the management roll-up. Decide which in the room. The first option changes the ontology and a data mapping, so it goes back to the super user as a change request.

​

3. Decide on the management roll-up

Ask: “Should a manager see what their direct and indirect reports can see?” If yes, the policy uses the reporting relationship as a management axis. This is optional. It widens access for everyone with reports, so the sponsor should agree.

​

4. Agree the test personas

Pick at least three real pilot users at different levels. One account cannot tell a working policy from a broken one. For each persona, write down which golden questions they will ask and what you expect them to see.

​

5. Agree the rollout

Access control has three modes, set in Administer > System Settings (GRAPH_AUTHORIZATION_MODE): Agree a date for shadow, a date for enforce, and who signs off the switch.

​

Worked example: Northbridge Consulting

Helen Park (Contracts Counsel) states the rule: “Contracts are confidential. Legal and the people on the engagement may see them. Everyone can see clients, projects and people.” Priya Shah (COO) confirms that managers should see what their teams see. Classification How people reach contracts (read each row as: hold the left, and you may also read the right)

• Grant rule (team): WORKS_ON_PROJECT. A consultant holds the projects they are staffed on.
• Legal: Helen’s team is never staffed on projects. The room agrees to add one relationship to the ontology, Employee COUNSEL_FOR → Client, loaded from a small legal_coverage.csv that Helen maintains. A second team grant rule on COUNSEL_FOR gives Legal the clients they cover, and the last row above gives them those clients’ contracts.
• Management roll-up: REPORTS_TO (stored report → manager), entered as a roll-up axis with direction up and attached to no baseline.

Test personas

​

Entering it in Experio

Policy rows are database rows entered in the staff admin, not configuration that ships with a release. Nothing is seeded. Only a staff administrator can edit them. Follow the order in Setting up a new deployment exactly:

​

What users will notice

• Fewer citations. Citations are filtered by the user’s access. On a broad question (“list all our contracts”), a restricted user can get a correctly scoped answer with no citation chips, because the sample the citations are drawn from is capped before filtering. A narrower question, naming a client or project, brings citations back. Tell pilot users this before enforce. See Citations, and why a scoped answer can have none.
• Different answers to the same question. This is intended. Record the persona on every golden-question score after enforce.
• Records nobody can reach. Diagnostics counts them. Fix them upstream with a data mapping or an enrichment rule that adds the missing relationship, not by widening the policy.

​

Common pitfalls

​

Exit criteria

• Every entity type in the graph is classified private or public read, and the data owner has signed the list
• Every private type has at least one written path from a person (grant rule plus propagation)
• People who need access without being staffed have an agreed relationship, with an owner for its data
• Management roll-up decision recorded
• At least three test personas with expected results per golden question
• Policy rows entered in the staff admin in the documented order
• Preview as user matches the expected results for every persona; Diagnostics reviewed
• Shadow mode run with pilot users; sponsor sign-off recorded in the decision log
• Enforce date agreed, and pilot users told about fewer citations on broad questions

​

Next

Continue to Workshop 10: Assistants & Agent Flows. Re-score the golden questions per persona in Accuracy validation once the policy is in shadow mode.