--- title: "Share an Object" description: "Give another user or a role access to a draft object, choose Read or Write, decide whether to include lineage, and request access to objects you cannot open." ---
TL;DR
Open a draft object and click the Share icon to give a user or a role Read or Write access. Tick Lineage per recipient so they can also open the object's inputs. If you cannot open an object yourself, use Request Access to ask someone who can.
## What is it? Sharing grants another user or role access to a **single object** you are working on, without changing their platform-wide role. It is how you bring a colleague into a draft before it goes through approval. Sharing only applies while an object is in progress. Once an object is **Approved**, everyone with the relevant role permissions can read it, so there is nothing to share. :::note You can only share an object in **Draft** or **Pending Approval** status. The Share icon does not appear on approved objects. ::: Shareable object types are Data Elements, Features, Global Functions, Quality Profiles, Datasets, Models, Policies, Frameworks, Reports, and Reason Codes. Data Tables, Product Types, Global Variables, and Runtime Parameters are not shareable; access to those comes from role permissions alone. ## How to share
#### Open the Share dialog On the object's detail page, click the **Share** icon in the action bar at the top. The dialog opens with the object's owner shown at the top and two tabs, **Users** and **Roles**. You need write access to the object to share it. You do not have to be the owner.
#### Pick users or roles * **Users** shares with named individuals. Use **Add people to collaborate**. * **Roles** shares with everyone holding that role. Use **Add roles to collaborate**. Each share entry is one or the other, not both. Only users and roles whose role permissions already allow access to that object type appear in the list. If someone is missing, their role does not permit that object type, and an admin has to change it before you can share. :::tip The picker matches on **display name** only, not username or email. See the [FAQ entry](/references/faqs/#in-share-access-or-request-access-why-cant-i-find-the-user-i-search-for) if a colleague is not appearing. :::
#### Choose Read or Write Set each recipient's level in the **Access** column:
Level What it allows
Read Open and view the object.
Write Open, view, and edit the object. Write includes Read.
Remove Revoke this recipient's access when you save.
You cannot grant more than you hold. With Read access you can only pass on Read; with Write access, or as the owner, you can grant either.
#### Decide whether to include lineage Each recipient row has a **Lineage** checkbox, **cleared by default**. It controls whether the recipient also gets access to the object's inputs. * **Without lineage**, the recipient can open the object itself and nothing else. If it is a Feature built on unapproved Data Elements, they see the Feature but cannot open what feeds it. * **With lineage**, they also get access to each unapproved object upstream. A warning banner in the dialog tells you whether all, some, or none of the recipients will be able to reach the lineage. Click the highlighted words to see exactly which recipients and which objects are affected. Two things worth knowing before you rely on it: * You need write access to **every** object in the lineage. If you do not, the share is rejected. * Lineage access is recorded on each input object, not on the object you shared from. Revoking access to the parent later does **not** revoke the lineage grants, so remove those separately if you need to. :::note Already-approved inputs are skipped, since anyone with the right role can read them anyway. :::
#### Save Click **Save Changes**. Recipients are notified that access was granted. :::note Notifications always appear in the platform. They are also emailed if your admin has configured an email notification provider. See [Configure Platform Settings](/user-guide/admin-guide/configure-platform-settings/). ::: If a change clashes with access someone already holds through their role, the dialog blocks it and explains which users are affected. Role-level access wins, so you cannot use a per-object share to reduce it.
## Request access to an object When you open an object you do not have access to, you see **Access to this object is restricted**. If your role could hold that access, a **Request Access** button appears. In the dialog: * Pick the **Access Type** you need. If you already have Read, Write is the only option. * Tick **Request Access to Lineage Objects** if you also need the object's inputs. * Choose who to **Request access from**. The list contains users who hold write access to that specific object. Both you and the people you picked get a notification. When a granter clicks theirs, the Share dialog opens pre-filled with your request, so approving it is a matter of clicking **Save Changes**. To decline, they set your row to **Remove** instead. If your role could never hold that access, the request is blocked with a message pointing you to your admin. That is a role-permission problem, not a sharing one. ## Revoking access Open the Share dialog, set the recipient's **Access** to **Remove**, and click **Save Changes**. They are notified that access was revoked. Remember that lineage grants live on the input objects. Revoking access to the parent leaves those in place. ## What's next - [Configure Roles and Permissions](/user-guide/admin-guide/configure-roles/): the platform-wide permissions that decide who can be shared with at all - [Approve an Object](/user-guide/how-tos/approve-an-object/): what happens once the draft is ready to go further