Sharing

Share Apps, Workflows, Tables and Knowledge Bases without granting broader Project access than the recipient needs.

Lleverage can share individual Apps, Workflows, Tables and Knowledge Bases with an eligible person or role. Item sharing is separate from giving someone broad Admin or Builder access to the whole Project.

Choose the access boundary first

Before sharing, decide whether the person's responsibility is Project-wide or item-specific:

• use a built-in or custom Project role when the person needs a coherent set of capabilities across the Project;

• use Guest plus explicit item sharing when the person should see only selected resources;

• share a specific item when broader Project access would be unnecessary.

See Roles and Permissions for the current role model.

Share an item

Use the item's Share action to grant access to an eligible person or role. The share dialog distinguishes an existing Project member from a new invite, and the access becomes part of the recipient's effective access shown on the Members page.

Sharing one item does not silently broaden access to other Apps, Workflows, Tables or Knowledge Bases. App and Workflow permissions also remain separate resources.

A URL is not an access grant. If someone opens a shared or published link without the required Lleverage access, the normal access checks still apply.

Guest access

Guest is deliberately restrictive. A Guest starts without broad Project access, then receives only the items that have been explicitly shared with them.

This is useful for customers, reviewers or collaborators who should work with a narrow surface without gaining general Project visibility.

Verify before handoff

Use the Project Members page to inspect the person's effective access and its sources. When available to you, Preview as this member is the safest way to check the resulting experience before handing it over.

Good access hygiene

Keep access aligned to operational responsibility:

• prefer narrow item access over a broad role when that is enough;

• use custom roles for recurring responsibility patterns rather than accumulating one-off exceptions;

• review direct access when ownership changes;

• do not assume that possession of a link or organisation membership alone grants Project-resource access.