Access and Permissions

Access in Novant is granted through organizations and projects. Every person signs in with their own account, and what they can see and do is determined by their role in an organization and by any projects they’ve been invited to. This page is the complete reference for how that access is resolved.

Access Model

Access flows from two places:

• Organization membership – members of an organization automatically have access to every project the organization owns, including projects created later.

• Project invitations – people outside the organization can be invited to individual projects with a specific role.

There is no need to add organization members to a project team. Project teams exist to grant access to people outside the organization.

Organization Roles

Each member of an organization has one of two roles:

Role	Description
Admin	Manages the organization – members, billing, API keys, and projects.
Member	Works on the organization’s projects with Manager access to every project.

Both roles have full access to the organization’s projects. The difference is that admins also manage the organization itself.

Project Roles

Each person with access to a project has an effective project role:

Role	Description
Manager	Full control of the project, including settings and team.
Collaborator	Modify the project – sources, assets, spaces, zones, and logic.
Viewer	Read-only access to project data.

Organization members and admins are always Managers of the organization’s projects. External users have the role they were invited with.

Effective Access

A person’s role on a project is resolved as follows:

1. Organization admin or member – Manager. This cannot be lowered for an individual project.
2. Project team member – the role assigned when they were invited.
3. Anyone else – no access.

When more than one applies, the highest role wins. For example, if someone was invited to a project as a Viewer and later joins the organization that owns it, they become a Manager.

Because organization members always have access, they cannot be invited to the organization’s projects. Inviting a member’s email address returns an error explaining they already have access as an organization member.

Permission Reference

Organization

Action	Admin	Member
View organization projects and members	Yes	Yes
Create projects	Yes	No
Invite and remove members, change roles	Yes	No
Manage organization settings	Yes	No
Manage billing and subscription	Yes	No
Create organization API keys	Yes	No
Order hardware nodes	Yes	No

Project

Action	Org Admin	Manager	Collaborator	Viewer
View project data, live values, and trends	Yes	Yes	Yes	Yes
Modify sources, assets, spaces, zones, and logic	Yes	Yes	Yes	No
Write points and apply scenes	Yes	Yes	Yes	No
Use Explorer and import points	Yes	Yes	Yes	No
Manage Drive files	Yes	Yes	Yes	No
Invite and manage external users	Yes	Yes	No	No
Manage plugins, connections, and credentials	Yes	Yes	No	No
Create project API keys	Yes	Yes	No	No
View the audit log and API log	Yes	Yes	No	No
Export project data	Yes	Yes	No	No
Add or remove nodes	Yes	No	No	No
Resize or delete the project	Yes	No	No	No

Organization members appear in this table as Managers.

External Users

External users are people outside the organization – consultants, vendors, contractors, or customers – who need access to specific projects. A project Manager invites them by email with a Manager, Collaborator, or Viewer role.

External users only see the projects they’ve been invited to. These appear on their Shared Projects page rather than under an organization. An external user can leave a project at any time; organization members can’t, since their access comes from the organization.

Removing Access

• Removing an organization member revokes their access to every project the organization owns, and removes any project team entries they had on those projects. Access to projects owned by other organizations is not affected.

• Removing an external user from a project team, or the user leaving the project, revokes access to that project only.

Changes to access take effect immediately.

API Keys

API keys grant programmatic access independently of individual people:

Key	Prefix	Scope	Created by
Project	ak_	A single project	Project Managers
Organization	ak_org_	Every project in the organization	Organization admins

API keys are not tied to the person who created them, so they keep working if that person leaves. Revoke keys you no longer need. See API Authentication for details.

Audit Trail

Changes made in a project are recorded in its audit log along with the person who made them, whether they’re an organization member or an external user. Requests made with API keys are recorded in the project’s API log.