Members

Manage Project membership, built-in and custom roles, effective access and member previews in Lleverage.

Use Members to manage who belongs to a Project and to understand the access each person actually has.

The page brings direct membership, inherited organisation access and other access sources into one view. When access is not obvious, open the member's access details rather than inferring permissions from the role label alone.

Project roles

The built-in Project roles are Admin, Builder, Operator and Guest. Projects can also define custom roles with narrower area and item permissions.

• Use Admin for people who need full Project administration.

• Use Builder for people who create and improve Project capabilities.

• Use Operator for people who run the operational experience made available to them.

• Use Guest when someone should start with no broad Project access and only receive explicitly shared items.

• Use a custom role when the built-in roles are broader than the person's responsibility.

Project Members showing a custom role, Guest access and item-specific access

For the complete model, see Roles and Permissions.

Configure access in practice

For a normal Project handoff, use this sequence:

1. Open Control → Members and add or invite the person.

2. Choose the narrowest built-in role that matches their responsibility. If the built-in roles are too broad, use a Project-specific custom role with None, View or Edit for the relevant areas.

3. If the person only needs a specific App, Workflow, Table or Knowledge Base, prefer Guest + item sharing instead of broadening their Project role.

4. Use Preview as this member before handoff when the access boundary is not obvious.

5. If the result is unexpected, inspect the person's effective access and access sources in Members before changing roles. Their access may also come from organisation ownership, directory or local groups, or item-level sharing.

This keeps the access decision tied to the person's real operational responsibility and gives you a repeatable way to verify the result before they start using the Project.

Add or invite people

From the Project's Members page, add an existing organisation member or invite a new person, then choose the narrowest appropriate role.

Custom roles can be assigned directly to people. If a person only needs a specific App, Workflow, Table or Knowledge Base, prefer item sharing over giving a broader Project role.

Understand effective access

A person's access can come from several sources. For example, they may have a direct Project role, inherited organisation-owner access, a group grant, or access to a specific item.

The Members page shows the effective result and its sources. This is the canonical place to investigate why someone can or cannot reach part of a Project.

Organisation ownership

An Organisation Owner has effective Project Admin access even if there is no direct Project membership row. Their inherited access is managed at organisation level, not from the Project member-role selector.

Preview as a member

Where your own access allows it, choose Preview as this member to inspect the Project from that person's effective access boundary.

Use preview before an invitation or access change when you need confidence about what the customer or colleague will actually see. A visible preview state identifies whose access you are inspecting. Exiting preview returns to your own access; preview does not mutate the member's permissions.

Review access over time

Revisit Project access when responsibilities change. Prefer the narrowest durable role or item grant that matches the person's work, and remove direct access that is no longer needed instead of relying on UI hiding alone.