Skip to main content
A grid is normally visible only to the person who created it. Sharing lets you give named teammates in the same account access to the grid you built, so they work from the same server-backed data instead of rebuilding it or trading exports. Existing grids stay private until you explicitly share them.

​
Who can share, and what they can grant

Any grid owner — whether an Organization User or an Admin — can share a grid they own. Open the Share dialog, find a named, active teammate in the same account, and give them one of two access levels; you can change or revoke it later.
The Share dialog - search a teammate and set their access level
Grid permissions are separate from account roles. Being an Organization Admin does not bypass a grid’s permissions, and a grid grant never gives someone account-admin abilities. Sharing across accounts is not possible.

​
Access levels

​
View-only

A viewer can:
  • Read the same server-backed grid data, columns, and the grid’s saved scope and filter presets.
  • Download data exports.
  • Sort, filter, arrange columns, and switch views locally. These stay personal to them — nothing is synced back to the grid or to you.
A viewer cannot edit cells, columns, metadata, or scope; save action configurations; duplicate the grid; run, refresh, or cancel computations; approve or register prices; or change sharing. Their exploring saves no state on the server.

​
Edit

An editor can do everything an owner can except delete the grid or manage its access grants. Existing organization permission checks still apply on top — for example, actions that need an account permission still need it. If an editor duplicates the grid, the copy belongs to them and starts private, with no inherited sharing.

​
Grant, change, or revoke access

Only the owner can grant, change, or revoke access, and only the owner can delete a shared grid. As an owner you select an eligible teammate and give them view-only or edit access, adjust that level later, or revoke it. Shared grids appear alongside your own on the Grids home page, showing the owner and your current access level, so it’s clear which grids are yours and which were shared with you.

​
How revocation and lifecycle behave

  • Changes apply on the next request. Revoking access, or downgrading an editor to view-only, takes effect on the recipient’s next action — including from a session they already have open. The UI reflects their effective access, and direct API calls enforce the same limits.
  • A run already accepted may finish. Jobs a user started before a change may complete; anything after uses their current access. Nothing is retroactively cancelled.
  • Inactive teammates lose access but keep their grant. A deactivated recipient can’t reach the grid; their grant is stored and resumes if they’re reactivated.
  • Deactivating the owner doesn’t remove teammates’ access. Their existing access continues.