User Guide

Share an Object

Ask AI

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.

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.

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.

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.

Save

Click Save Changes. Recipients are notified that access was granted.

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: the platform-wide permissions that decide who can be shared with at all
Approve an Object: what happens once the draft is ready to go further

Was this page helpful?

Thanks for the feedback.