Skip to main content
Everything you build in a workspace belongs to someone and can be shared with others. This article describes the permission model: who owns what, what each access level means, how sharing works, and how Membrane keeps shared elements usable by surfacing their dependencies.

​
Ownership

Every shareable element has an owner: the tenant it was created for. Ownership is itself recorded as a grant — the highest rung of the ladder — and it means administration: the owner assigns access levels, approves requests, and can transfer ownership. When you create an element you also receive its full acting capability (see below), so as a creator you can both run the element and govern it; ownership can be transferred without re-sharing everything else.

​
Access Levels and Capabilities

Access has two independent axes. Levels form a ladder; each level includes everything below it: Capabilities cover acting through an element, and are separate from levels — holding edit on a connection does not let you run requests through it, and being able to run requests does not let you reconfigure it. Capabilities exist per element type, for example:
  • Connections: full access, read data, write data, and per-action run rights.
  • Data tables: full access, read records, write records.
  • Jobs: operate — held by every operator in the job’s crew, the team that runs it together. Operator assignment grants it; sharing never does.
A property worth calling out with connections as the example: a data capability lets the grantee execute through the credentialed link, but credentials themselves are never exposed. Sharing a connection this way is safe in a way that sharing credentials never is. What each level and capability allows for a specific element type — and that type’s default visibility — is listed in the Permissions section of the element’s own reference page.

​
Who You Can Share With

An element can be shared with five kinds of audience:
  • The whole workspace — one grant that covers every workspace member.
  • Specific people — individual grants, each with its own access level.
  • A job’s operators — everyone on that job’s crew.
  • The workspace’s operators — everyone on the workspace’s crew, which operates every job in the workspace.
  • Anyone with the link — an anonymous, view-only public link, available only where the element’s reference page says so.
The two operator audiences are standing arrangements rather than lists of people. The grant reaches whoever is on the crew at the moment access is checked, so an operator who joins next week needs no second share, and an operator who leaves the crew loses the reach the same day. A person’s effective access is the highest level that reaches them — their individual grant, a crew grant that covers them, or the workspace-wide grant, whichever is highest. The owner sits above all grants. Only the owner or someone with manage access can change sharing.

​
Default Visibility

When you create an element, it starts either visible to the workspace (everyone can see it exists and read its non-secret configuration, but only the owner can use, edit, or manage it) or private to you. Which of the two applies is part of each element type’s reference page. You can tighten or widen visibility afterwards from the element’s sharing control.

​
Inherited Permissions

Some elements never hold their own grants — they inherit sharing from their parent. A job’s routines, tasks, deliverables, and receipts work this way: their headers show “Inherited from job” instead of an editable sharing control, and what crosses is defined per relationship — the job’s operator works its records while other audiences see them read-only. Inheritance means there is never a gap inside such a group — you cannot share the parent and forget its parts.

​
Requesting Access

When you open something you don’t have access to, you don’t hit a dead end — you see a request access screen. Pick the level you need, optionally add a message, and the owner receives an actionable request in their inbox. Approving it creates the grant in one click; you’re notified either way.

​
How Enforcement Works

Every operation in Membrane — from the console, the API, the CLI, or an agent — goes through the same access check. Each operation declares what it requires on the elements it touches (for example, reading a table’s records requires the read records capability on that table; sharing anything requires manage on it). If your effective access doesn’t satisfy the requirement, the operation fails with a clear 403 explaining what you’d need and what you currently have.

​
Dependencies Sharing

Elements often need other elements to work — a canvas reads tables, a job acts through connections. Sharing an element doesn’t automatically share what it depends on: a canvas shared with the workspace still fetches data as each viewer, so a viewer without access to the underlying tables sees errors instead of data. Membrane surfaces these gaps instead of silently widening access:
  • When you share, the share flow lists what the audience is still missing and offers a one-click grant at the minimum level needed — or a one-click request to the dependency’s owner when it isn’t yours to share.
  • On the element, the sharing control warns while gaps exist — including when a dependency’s sharing is revoked later.
  • For viewers, a blocked element names the dependency that failed and offers to request access to it directly.
  • When you revoke access to an element that shared elements depend on, Membrane warns you before applying.
Only dependencies that the audience’s own interaction runs through count: for workspace members, canvas blocks fetch as the viewer, so a shared canvas needs its tables shared too — but a sync that fills a table runs as its owner, so viewing the table needs nothing extra. The one deliberate exception is “anyone with the link” canvas access: the canvas is the thing being shared, so its blocks render server-side on the owner’s behalf, read-only and for that canvas alone — a link never confers access to the underlying elements themselves.