Information barriers

An information barrier keeps restricted projects away from the members on the other side of it. Its typical use is a member who holds a public office and must not see the organization's strategy on matters that office decides.

What a barrier does

A barrier has walled projects, which must be restricted, and excluded members. For an excluded member:

• the walled projects, and their issues, initiatives and research notes, disappear from lists, details, search, timelines and link panels;
• opening a walled record, in the app or through the API, shows "not found": the same answer as for a record that does not exist;
• links across the barrier are refused, between a walled record and a workspace record outside it, in either direction.

Everyone else works as before. Governance records (interests, disclosures, recusals, barriers) and public sources are neutral: they may point at walled records, so a recusal can name the decision it is about.

A barrier stops applying to a project as soon as the project is no longer restricted. Restrict it again and the barrier applies again.

Automatic barriers

When a member's interest is a Track A role flagged holds public office or appointment (Conflicts) and the role is linked to a restricted project, a barrier is created automatically:

• one barrier per role and project, named Public office: <role>;
• the project walled, the role's holder excluded;
• created by the system, and recorded in the audit log.

It is created when the interest is saved or the link is made. If the project is restricted only later, it is created within moments of the change.

Automatic barriers are never lifted automatically. Ending or withdrawing the role leaves the barrier in place until an owner lifts it.

In a personal workspace an automatic barrier is a link wall only. Excluding the only member would lock them out of their own work, so nothing is hidden, but links across the barrier are still refused.

Managing barriers (owners)

Go to Trust → Barriers, or Admin → Retention and barriers.

• Create a barrier with a name and a reason.
• Set its projects. Each must be restricted.
• Set its members. Each must be a member of the workspace.
• Lift it, with a reason. A lifted barrier stays in the list, marked lifted, with who lifted it and why.

An owner whom a barrier excludes cannot lift it, unless they are the workspace's only owner.

Excluded members are notified when a barrier starts or stops applying to them (An information barrier starts or stops applying to you in Notifications). Every change is recorded in the audit log.

Barriers that apply to you

Any member can open Trust to see the barriers that exclude them, with each barrier's name and reason. The names of the walled projects are not shown.

What else a barrier hides

Besides the walled projects and their records, an excluded member or owner does not get:

• audit log entries about walled records (Admin → Audit log);
• notifications about walled records, from any part of the app, nor walled items in their copy of the weekly digest, by email or in Digests;
• walled projects in their own list of roles, even where they hold a role in one;
• records from walled projects in a personal-data export they prepare (Data requests). The export says how many records it left out ("withheld"), and the request stays open so that an owner the barrier does not name can prepare a complete one;
• the export of all the organization's data. An owner a barrier excludes cannot request or download one, because it would include the walled projects. Another owner can.