Roles & permissions

How access works in Elliptic

Access in Elliptic is layered. Every person and every agent in your organization carries one org role that sets their baseline across the whole workspace. On top of that, each project can give them a separate project role that only applies inside that project. And when those two built-in axes are not specific enough, an admin can define custom roles that carry an exact set of permissions, plus a permission matrix that narrows access resource by resource and action by action.

The model is deliberately additive and restrictive. Owners and admins always have everything. A plain member starts from a sensible baseline. Custom roles can only ever grant a member more on the permission side, or narrow them on the matrix side, and never touch what owners and admins can do. This page walks each layer in order, then ends with a quick who-can-do-what reference.

Built-in organization roles

Membership in an organization always comes with exactly one org role. There are four, and they form a strict hierarchy from least to most powerful: guest, member, admin, owner. Each higher role can do everything the role beneath it can, and endpoints across the product gate themselves on a minimum role, so granting someone admin automatically gives them every member capability as well.

Because the hierarchy is strict, the question an endpoint asks is always "is this caller's role at least X". Inviting and removing members, changing roles, and editing org settings require admin or higher. Granting owner requires owner. There is no way to be, say, an admin for billing but a member everywhere else through the built-in roles alone. That kind of slicing is exactly what custom roles and the permission matrix exist for.

Owner protection

An organization always keeps at least one owner. Elliptic enforces this directly: you cannot demote the last remaining owner to a lower role, and you cannot remove the last remaining owner from the org. Only an owner may remove another owner, or grant the owner role to someone else.

You also cannot change your own role. This keeps an admin from quietly self-promoting and keeps an owner from accidentally self-demoting out of control while other owners exist. Role changes always target someone else.

Guest limits

Guests are designed for contractors, clients, or anyone outside the core team who needs to see or comment on a slice of work without becoming a full member. Their limits are enforced, not just conventions:

• Capped to viewer or commenter on projects. A guest may only hold the viewer or commenter project role. Trying to give a guest the member or admin project role is rejected.
• Never an assignee. A guest cannot be set as a project's intake owner or default assignee, and work items cannot be assigned to a guest.
• Free seats. Guests do not consume a billable seat. Owners, admins, and members are billable, guests are not, which is what makes them safe to hand out widely.

These rules are also enforced retroactively when someone is downgraded. If you change an existing member into a guest, Elliptic automatically pulls any of their over-cap project memberships down to commenter and clears every work item currently assigned to them, so the guest invariants always hold the moment the role changes.

Project roles

The org role is the workspace-wide baseline. A project role is the second axis: it is granted per project, when someone is added as a project member, and it only governs what they can do inside that one project. The two combine, the org role sets the ceiling and the project role sets the access within a given project.

There are four project roles, also ranked from least to most powerful:

How the two axes combine in practice: your org role decides whether you can exist in the org at all and what org-wide actions you can take, while your project role decides your reach inside each specific project you belong to. A member of the org can be a project admin on one project and only a viewer on another. A guest, by contrast, is capped at commenter no matter what, because the guest org role overrides any attempt to grant more inside a project. For the full membership flow, default roles, and how public versus private projects affect joining, see the Projects & Tasks page.

Custom roles

Sometimes owner, admin, member, and guest are too coarse. You want a "Release manager" who can manage automations and integrations but should not touch billing, or a "Recruiter" who can invite members but cannot create projects. That is what custom roles are for. A custom role is a named role you define inside your org that carries a precise set of permissions, and you attach it on top of someone's base member role.

Custom roles live in Settings → Roles. Creating, editing, assigning, and deleting them requires admin or higher. Each role has a name that is unique within the org, an optional description, the set of permissions it grants, and an optional permission matrix (covered in the next section).

The permission catalog

A custom role is built from a fixed catalog of twelve permission keys. You pick the ones the role should grant. These are the same keys the product checks when gating an action:

Keys outside this catalog are simply ignored. When a role is saved, Elliptic drops any permission that is not one of the twelve and de-duplicates the rest, so a role always carries a clean, well-formed set.

Defining and assigning a role

1. 1
   Open the Roles settings

   Go to Settings → Roles. You see the list of existing custom roles and a form to create a new one.
2. 2
   Name the role

   Give it a clear name like Release manager. The name must be unique within the organization, and creating a role with a name already in use is rejected.
3. 3
   Pick its permissions

   Check the permission keys from the catalog that this role should grant. The create form requires a name and at least one permission before it will submit.
4. 4
   Optionally narrow with the matrix

   If you want this role to be more restricted than a normal member on specific resources, set matrix cells (see the next section). Leave the matrix empty to grant without narrowing.
5. 5
   Create, then assign

   Save the role. Then assign it to a member, which attaches the custom role to that member's membership and layers its grants on top of their base member role. A membership holds at most one custom role at a time.

How effective permissions resolve

At any moment, a caller has a set of effective permissions. Elliptic resolves them like this:

• Owners and admins always have every permission in the catalog. Custom roles do not apply to them and cannot reduce them.
• A plain member starts from a base set: projects.create, tasks.create, tasks.assign, and notes.publish. This is what every member can do without any custom role.
• A member with a custom role gets the base set plus whatever the role grants. The two are unioned, so a custom role can only ever add permissions to a member, never remove them.

Because custom-role permissions are purely additive for members, they are the right tool to extend a member, give a trusted member the ability to manage integrations, say, without making them a full admin. To restrict a member below the member baseline on specific resources, use the permission matrix instead.

The permission matrix

The permission catalog answers org-wide yes-or-no questions. The permission matrix is finer. It lets a custom role narrow access on a per-resource, per-action basis, so you can say a role may edit only its own work items, or may read every project but create none. The matrix is the restrictive counterpart to the additive permission catalog.

The matrix is a grid. Rows are resources, columns are actions on that resource, and each cell holds one of four values.

Each cell you set takes one of four values, from most restrictive to least:

The additive-restrictive rule

The matrix only ever narrows access, and only for members an admin has explicitly constrained. The evaluation, for any resource and action, is:

• Owners and admins always allow. The matrix never applies to them.
• A member with no custom role always allows. Without a custom role there is no matrix to consult, so the member baseline stands.
• An unset cell always allows. If a member has a custom role but that role leaves this particular cell blank, the action is permitted. You only restrict the cells you deliberately set.
• A set cell resolves by its value: none denies, own permits only when the caller owns the item, lead permits only when the caller is the lead, and all permits.

When you save a matrix, Elliptic keeps only the cells that name a known resource, a valid action for that resource, and one of the four valid values. Anything else is dropped, so a role's stored matrix is always well-formed.

Worked example

Say you want a "Contributor" custom role for members who should fully participate but only edit and delete their own work items, while still reading everything. You would grant the tasks.create permission and set these matrix cells on the tasks resource:

{
  "tasks": {
    "read": "all",
    "update": "own",
    "delete": "own"
  }
}

A member assigned this role can read every work item, but can only update or delete items they own. The create action is left unset, so it inherits the member baseline and stays allowed. Owners and admins are unaffected, they still do everything.

Quick reference

Putting the layers together, here is who can do what. "Org" columns are the built-in roles, and the rightmost column shows when a plain member's access can be changed by a custom role.

If you are choosing how to scope someone, the order of thinking is: pick the right org role first, since it sets the ceiling and decides billing. Use project roles to control reach project by project. Reach for a custom role only when you need to extend a member with specific powers or narrow them on specific resources. And whenever you constrain through the matrix, remember that owners, admins, and every cell you leave blank still allow, so you are only ever carving out the exceptions you set on purpose.