> For the complete documentation index, see [llms.txt](https://docs.lleverage.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lleverage.ai/build-and-improve/automate/publish-apps-and-apis/sharing.md).

# 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](/administer-and-govern/control/members/roles-and-permissions.md) 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.lleverage.ai/build-and-improve/automate/publish-apps-and-apis/sharing.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.