Roles and access
ApexAV controls access by role. Every person in your Company holds exactly one role, and the role decides what they can do. The matrix below is the default and the only one: it is fixed in the platform, the same for every Company, and cannot be edited per workspace.
Partners (your outside AV integrators) do not hold a Company role. Their access is granted separately, and that is covered in the second half of this page.
The nine Company roles
One rule first, because it shapes the whole table: everyone in a Company sees every project. Visibility is workspace-wide. The role decides what a person can change, not what they can see.
| Role | Admin | Transfer | Edit | Field | Audit | Money | Connect |
|---|---|---|---|---|---|---|---|
| Owner | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Administrator | Yes | Yes | Yes | Yes | Yes | Yes | |
| Project Manager | Yes | Yes | Yes | Yes | |||
| Leadership | Yes | ||||||
| Field Operations | Yes | ||||||
| Auditor | Yes | Yes | |||||
| Security Auditor | Yes | Yes | |||||
| Financial Auditor | Yes | ||||||
| Viewer |
A blank cell means the role cannot do it. Every role can read every project, room, device, visit and license in the workspace.
What each column means
- Admin. The Administration area: invite and remove users, change roles, account settings, system health, exports.
- Transfer. Delete the workspace or transfer it to someone else. Owner only.
- Edit. Create projects and change their plans, baselines, risks and change orders, on any project in the workspace.
- Field. Field work: tasks, documents, equipment updates, and site visits, from proposing through marking on-site and done.
- Audit. Read the workspace audit log.
- Money. Budgets, actuals, baselines, cost variance, and license spend. Roles without it see the work but not the figures.
- Connect. Administration > Connectors: add platform credentials, run a sync, change schedules.
Reading the table
- Owner and Administrator are the two management roles. The only difference is ownership: an Administrator cannot delete the workspace or hand it to someone else.
- Project Manager is the full working role: everything about projects and field work, plus the money and the connectors, but no Administration area.
- Field Operations is the on-site role: site visits, equipment and documents, no project governance and no figures.
- Leadership is an executive read: every project with the money, nothing to click that changes anything.
- Auditor and Security Auditor read everything including the audit log and the money. They differ in name only today; the split exists so the two oversight jobs can diverge later without a role rename.
- Financial Auditor reads everything and the money, but not the audit log.
- Viewer reads everything and changes nothing.
View as
Owners and Administrators have a "view as" tool that previews the product as a lower role, so you can confirm what a Viewer or a Field Operations user will actually see before you invite them.
Choosing a role
| The person | Give them |
|---|---|
| You, or a co-owner of the account | Owner |
| Runs the operation: users, partners, settings | Administrator |
| Manages projects, schedules, budgets and the team | Project Manager |
| An executive who wants the picture and the figures, read-only | Leadership |
| Does on-site work and field documentation | Field Operations |
| Compliance or internal audit, needs the audit log | Auditor or Security Auditor |
| Finance, needs the figures but not the audit log | Financial Auditor |
| A stakeholder who only needs to look | Viewer |
WARNING
Owner can delete the workspace and change who owns it. Grant it only to people who carry that responsibility. To move ownership, change the existing Owner's role rather than handing out a second Owner login.
Partner access
Partners work inside your workspace through the Partner portal, under access you grant. Two layers decide what a partner's people can do, and the answer is always the narrower of the two.
Layer one: what your Company grants
Per project. When you invite a partner to a project you pick a profile for them on that project: read only, field operator, collaborator, or delegated manager. Read only is the default, and an invited partner is not an empowered one until you change it. Today the line the platform enforces is read only against the other three: read only can look, the other three can write to that project. The three write profiles are labels for how you intend the partner to work; finer differences between them are not yet enforced.
Per domain. Administration > Partners lets you share whole areas of the workspace with a partner organization at one of three levels:
| Level | Means |
|---|---|
| View | See the area |
| Work | Do the day-to-day work in it |
| Manage | Change how the area is set up |
The areas are Projects, Field Ops and Infrastructure today. Sites, Reports and Support appear in the sharing console as coming soon and cannot be granted yet. A grant is workspace-wide, or narrowed to one project. A project-specific grant always wins over the workspace grant for that area, even when it is lower, which is how you narrow one partner on one sensitive project without touching their access everywhere else.
Layer two: the partner's own role
The partner organization decides which of its people act on your grant. Each partner user has a role inside their own company, and that role caps what any grant can give them:
| Partner's internal role | Cap |
|---|---|
| Owner, Admin | No cap. Whatever you granted. |
| Sales Manager, Project Manager, Designer, Estimator, Procurement, Dispatch Coordinator, Field Technician, Field Installer | Work at most, even if you granted Manage |
| Viewer, or any role the platform does not recognize | View at most |
So a partner's field technician can never manage your Infrastructure area, however generous your grant, and a partner's viewer can never write anything in your workspace.
The partner roles, from the partner's side
A partner organization has eleven roles to give its own people. Three tiers matter; the rest is labelling.
| Tier | Roles | Inside their own Partner portal | On your projects |
|---|---|---|---|
| Administration | Owner, Admin | Manage the partner's team: invite people, set and change their roles, remove them. An Admin cannot change or remove the Owner, or make anyone else an Owner. | Uncapped: whatever you granted. |
| Operational | Sales Manager, Project Manager, Designer, Estimator, Procurement, Dispatch Coordinator, Field Technician, Field Installer | Everything in the portal except team management. The eight titles are organizational labels with identical access today; they describe the person, they do not restrict them. | Work at most. Write access on a given project still needs a write profile from you. |
| Read-only | Viewer | Look, never change. | View at most, whatever profile or grant you set. |
Two rules a partner admin should know:
- A person whose role was never set is treated as Viewer. A partner org's first user sometimes starts this way; until an Owner or Admin seats them with a role, every write they attempt is refused with a message saying so.
- Both sides have to agree before a write goes through. The Company's profile or grant has to allow it, and the person's own role has to allow it. Either one alone is not enough.
What a partner never gets
- Any Company role, or the Administration area.
- Anything outside the projects and areas you granted.
- Another Company's data. A partner who works with two Companies sees each one only from inside that Company's workspace, with a band across the top naming which one they are in.
How access is enforced
Role checks run on the server on every request, before any data is returned, so editing a URL cannot reach a screen or an action outside the role. Partner checks resolve both layers above on every request and fail closed: a missing or unrecognized grant, level or role means no access, never a default of access. Separation between Companies is enforced by the database itself. The details are in Data isolation and security.