Layers

A Layer is a named condition context within a Project. Selecting it applies its rule to calculated Views and changes how property defaults and conditions are presented and authored. It is not a separate Project, a copy of the data, or a saved View.

Layers also support scoped access for people who do not have Project-wide access. This is different from a Project member choosing a Layer to focus their work: choosing a Layer does not remove that member's existing permissions.

Permissions and scope

Project access is inherited into its Layers. A direct Layer assignment can elevate inherited access, but cannot lower it. Removing that assignment does not revoke access inherited through a Team, Space, or Project. Review Workspace permissions before using a Layer as an access boundary.

Matching resources only affects scoped reads for Layer-only users. When enabled, they see matching resources and the ancestors needed to reach them. When disabled, they can see the complete resource structure, still with Layer-filtered values. People who already have Project-wide access retain the full Project tree even when working in that Layer. Structural ancestors are navigation context, not a grant to unrelated data.

Layer-only access currently does not grant file download/upload or Project-scoped assistant access. See Files and AI assistant. A visible attachment or navigation path is not proof that these separate operations are authorized.

Create a Layer

Prerequisite: Manager or higher Project access and existing resources or properties suitable for the rule.

1. Open the Project menu in the workspace header and choose Edit layers. This opens the Layers section of Project administration. Details and permissions also opens Project administration.
2. Select Add layer.
3. Enter a nonempty Layer name that is unique within the Project. Names are compared without surrounding spaces or letter-case differences.
4. Build a complete condition rule. Select the Class or property operand, its comparison, and any required target or value.
5. Choose whether to enable Matching resources only for Layer-only users.
6. Select Add layer and wait for the action to finish.

The saved Layer appears in the administration list and is selected there for inspection. Selecting a row in administration is not the same as activating that Layer in the data workspace. Return to the workspace and select it in the Project menu.

The fictional Product Atlas demo defines Northland market, using a Markets Class rule selecting Northland, with Matching resources only turned off. Prepare the Markets Class and Northland Value first if reproducing it in an empty practice Project. If that Layer already exists, select it rather than creating a duplicate. Creating a Layer does not create its resources, assign people, or supply missing product references.

Build and change the filter

The Layer editor uses the same rule builder as Conditions. Class predicates select resource contexts; property predicates compare typed values or compatible properties. Available comparisons depend on the selected operand.

• Use Add condition for another predicate and Add group for a nested group.
• With multiple children, change the group's AND or OR operator. AND requires all children; OR requires at least one.
• Drag the rule handles to rearrange predicates or groups. Use the remove controls to delete unwanted children; a group must retain at least one condition.
• Complete every required comparison and target before saving. A partially filled rule prevents the save action.

To rename a Layer, change its rule, or change matching-only behavior:

1. Open Project administration > Layers and select the Layer row.
2. Select Edit layer.
3. Adjust the name, resource restriction, or rule.
4. Select Save layer and wait for success.

Cancel discards the modal edits. Saving changes the named context and can change what Layer-only members can read. Review the rule carefully before broadening access.

Existing contextual conditions retain the rule that was saved when they were authored. Renaming or editing a Layer does not rewrite all earlier conditions to its new rule. After changing a rule, inspect relevant conditions in All data and confirm that they still express the intended context.

Switch between Layers and All data

1. Open the Project menu in the workspace header.
2. Search the Layer names if needed; the menu filters by name without regard to letter case.
3. Select an accessible Layer, or select All data when you have Project-wide access.
4. Check the active Layer name in the header and View pane before editing.

The selected Layer changes the workspace context and calculated results, not the saved View's identity. A View's own filter is combined with the active Layer. Onepager boxes and Timeline series may further narrow the context; see Views, Onepager, and Timeline.

The workspace address records the selected Layer. Opening that address still requires authorization; the link never grants access. If a requested Layer is deleted or inaccessible, the app falls back to All data for a Project member, or to an accessible Layer for a Layer-only member. Layer-only members cannot use All data as an unrestricted workspace and are automatically placed in an accessible Layer.

Layer menu search is only a selector filter. It is distinct from Resources search and global search, and there is no ordinary Layer reorder control in the administration list.

Edit data in context

While a Layer is active, the property card's top Default input is contextual. Saving it creates or updates an override for that Layer's rule without changing the global default. Compatible conditions are presented relative to the Layer; conditions that clearly conflict with it are hidden. A condition not proven incompatible may still be shown, so visibility alone does not mean every predicate is already satisfied.

New conditions include the active Layer rule. If an editable condition is broader than the Layer, a contextual edit can create a narrower condition while preserving the original. Inspect All data when you need to compare the original and contextual rules. See Properties and Conditions.

For Project Editors, adding a property while in a Layer makes its initial value contextual rather than a new unconditional default. A Layer-only Editor does not gain permission to create or rename project-wide field families or restructure resources. Structural property and condition reordering is unavailable while a Layer is active; use All data with the required Project access.

In Resources Table mode, a contextual reference cell edits the complete effective reference set. Saving produces a replacement for that Layer, not a sequence of incremental additions and subtractions. Contextual Onepager reference drops may include the Layer, page, box, and rendered Class context. These actions change data, unlike merely changing a View filter.

The selected snapshot still matters. A Layer is a condition context, not a new time period. Confirm both the Layer and snapshot before saving.

Manage existing Layer assignments

1. Open Project administration > Layers and select the Layer.
2. Review its permissions grid. This section shows Direct permissions, not the complete list of everyone who inherits Project access.
3. Use Search permissions to find an existing direct assignee.
4. To change that assignment, select an allowed role on its role slider and wait for the update.
5. To remove it, select Remove direct role on that row and wait for the result.

You cannot change or remove your own direct assignment through these controls. An assignment must remain above the member's inherited Project role. Managers can grant through Editor, Admins through Admin, and Owners through Owner; disallowed roles are not available. The administration page itself still requires the relevant Project access, so a Layer assignment alone does not guarantee access to every administration control.

Removing a direct assignment leaves inherited access intact. For a Layer-only user with no other qualifying access, removal prevents continued use of that Layer; another accessible Layer may remain available.

The current Layer section has no Invite or Add member control. It can change or remove existing assignments, but does not provide a complete UI workflow for granting a first Layer-only assignment. The invitations elsewhere on Project administration grant Project access, not a Layer-only invitation. Do not use a Project invitation when the intended access should be limited to one Layer. New Layer-only assignment provisioning is outside the documented customer UI.

Delete a Layer

Prerequisite: Manager or higher Project access. Review direct assignments and dependent contextual data first.

1. Open Project administration > Layers and select the Layer.
2. Select Delete layer.
3. Type the Layer's exact displayed name into the confirmation field.
4. Select Delete Layer and wait for success.

The Layer and its direct assignments are removed. Existing conditioned values remain unchanged: deleting the named Layer does not delete its previously authored rules or return those overrides to the global default. The selector will no longer offer the Layer, and an active workspace falls back to an authorized context.

Use All data, with sufficient Project access, to inspect or deliberately remove remaining conditions. Do not assume Layer deletion is a cleanup of all related business data, or that it can always be reversed. Consult Undo.

Troubleshooting and limits

No access rule bypass, bulk Layer assignment import, first-assignment invitation flow, or unrestricted All-data mode for Layer-only users is provided by these controls. See Troubleshooting for connection and permission failures.