Project Teams
Projects in Novant are collaborative by design. Each project has its own team, defining who can view, edit, and manage that project. Teams make it simple to coordinate work across internal staff, external partners, and clients — while maintaining security and visibility boundaries.
Overview
A project team is the list of users who have access to a given project. Each team member has a defined role that controls what they can do within the project. You can invite both:
Internal users – members of your organization who already have Novant accounts under your organization.
External users – consultants, vendors, or customers who need access to collaborate on a specific project.
Projects are managed by an organization, and each organization defines how access is managed. Org admins have implicit access to all projects in their organization, but regular members must be explicitly invited to each project.
Why Create Teams
Project teams exist to provide visibility, coordination, and accountability:
Visibility – Know who has access and what they can do.
Coordination – Work seamlessly across internal and external contributors from a single source of truth.
Security – Limit access to only those invited. Each user’s role defines their permissions.
Traceability – Actions taken within a project are attributed to specific users, improving auditability and collaboration confidence.
Even if your organization has broad administrative access, defining clear teams ensures that everyone working on a project has appropriate, intentional visibility.
Organization Access Rules
Organization Admins – Always have full access to all projects owned by the organization. They do not need to be explicitly added to each project – but should always be added if they are actively involved in the project. Adding them ensures their participation is visible to other team members and included in project notifications and activity logs.
Organization Members – Do not have automatic access to all projects. They must be invited to each project’s team.
This design ensures that visibility is explicit – only users directly involved in a project can view or modify it.
Project Roles
Each project team member has a specific role defining their permissions within the project.
| Role | Manage Team | Modify Project | View Project |
|---|---|---|---|
| Manager | ✅ | ✅ | ✅ |
| Collaborator | ❌ | ✅ | ✅ |
| Viewer | ❌ | ❌ | ✅ |
Role Descriptions
Manager - Has full control of the project, including changing settings, inviting or removing team members, and editing project data. Typically assigned to project leads or internal staff responsible for delivery.
Collaborator – Can modify the project and contribute to configuration, data mapping, and analysis. They can view all project data but cannot change team membership or settings.
Viewer – Has read-only access. Useful for stakeholders, clients, or others who need visibility into project data but should not make edits.
Best Practices
- Assign Managers sparingly to limit administrative risk.
- Use Collaborators for day-to-day contributors.
- Add Viewers for external stakeholders or auditors who only need visibility.
- Review team membership periodically to ensure access remains current.