Resource sharing grants a person or group access to a specific workspace resource. Review the target and role together; a viewer grant and an editor grant support different work.
Resource metadata and grant operations are implemented. Native integration tools remain owner-only and reject sharing until credential-use approval is supported. A resource grant does not transfer a private credential or enable an unavailable runtime operation.
You need the resource ID and type, an existing workspace recipient, and permission to manage that resource’s sharing.
Inspect current access
Get resource with the correct resource_type. Review role_to_group_ids and share_options. Names and creator metadata may be absent, so keep the resource ID in your review. Choose a specific recipient
Share workspace resource accepts exactly one of user_email or group_id, together with resource_type and role. The accepted roles are viewer, commenter, editor, and admin. Choose the access needed for the intended work. Read the resulting grants
Request the metadata again and verify the target and role. Use Unshare workspace resource when removing the grant, then review other direct or group grants that may still provide access.
The special group_id value default targets the workspace. Use it only when workspace-wide sharing is intended. This is distinct from selecting a named user group.
Does sharing invite someone who is not a member?
No. The recipient must resolve to an existing workspace member or group. Manage invitations separately.
Does unsharing one grant remove all access?
Not necessarily. Other memberships, groups, or grants may still authorize access.