How APEX is put together
This page explains the thinking behind APEX: why it exists and how the pieces relate. It also marks the boundaries, the things APEX deliberately does not do. If you want to click through the product instead, start with the Get started tutorial. If you need a specific task done, the how-to guides are shorter.
The problem APEX exists to solve
AV operations usually live across many disconnected tools. Projects sit in a project tracker. Device health lives in a separate console per manufacturer. Field visits go on a dispatch tool or a shared calendar. Partner insurance certificates age in a spreadsheet of expiration dates, license renewals in another one. Executive reporting gets rebuilt by hand every quarter from all of the above.
Each tool is fine at its own job. None of them know about the others. A conference room can read healthy in the manufacturer console while its support contract expired last week in a spreadsheet the engineering team never opens. A single partner site visit can exist in three systems under three different IDs.
APEX puts that work on one shared set of records. A project, a room, a device, a partner, a license, and a site visit are each a single record, and every screen in the product is a different window onto the same records. Update a visit in Field Ops and every other view sees the same change, because there is only one visit.
Two ways teams run APEX
APEX serves two kinds of operation, and the same platform handles both at once.
An in-house AV or IT team runs its own company's AV operation. The team works in the Company portal and invites its own people. Outside partner companies come in on scoped access, limited to the projects those partners actually work.
An AV integrator or managed-service provider runs their whole book of clients through APEX. Each client is its own sealed workspace. The integrator's people sign in once to the Partner Portal and switch between clients from a single login. When they switch into a client that is not their home context, a band across the top of every page names the client they are working in, so a technician never posts an update into the wrong account.
An integrator can be both at once: an in-house operation for their own office's rooms and equipment, and a partner across the client workspaces they service.
Why your data stays separate
Every Company runs in its own workspace, and the separation is enforced by the database itself rather than by application code remembering to filter. A partner who works with two Companies sees each one only from inside that Company's workspace; nothing leaks sideways, even though it is the same partner organization on both sides.
Going deeper: the exact enforcement model, what the audit log records, and the platform's security posture are documented in [Data isolation and security](/reference/data-isolation-and-security).
One conversation per piece of work
The hardest part of AV operations is not the technology. It is the back-and-forth between the client's team and the partner companies doing the work, which email and chat scatter across dozens of threads. In APEX, each work item (a project, an equipment item, a room, an onsite visit) carries its own discussion thread, and both sides post into the same one.
Site visits go further: they have a structured lifecycle. A partner proposes dates, the client approves or counters with a reason, the partner marks on-site on arrival and marks done with a recorded outcome. Every state change lands in the thread automatically, so the audit trail writes itself while the work happens. Nobody reconstructs a status report after the fact.
How much the client participates is up to them. Some clients never log in at all and receive reports from their partner, while others hold a read-only login and watch the work. A co-managed client runs its own internal team in APEX alongside the partner, with some projects partner-led and others client-led.
Live device data from the platforms you already run
Room health and device inventory in APEX come from the manufacturer platforms you already operate. A connector signs in to the manufacturer's cloud on your Company's behalf and keeps device state current, so nobody re-types an inventory. Cisco Webex rooms (through Control Hub) and Logitech Sync fleets are connected today; the public roadmap tracks what is next.
Connectors are deliberately narrow. Each one performs a fixed set of actions and holds credentials scoped to your Company alone, and every call it makes to the outside platform lands in the audit log. APEX reads what the manufacturer platform knows. It does not probe your network or run its own monitoring against your devices.
What APEX is not
Knowing the boundaries saves you an evaluation cycle.
| APEX is not | Because |
|---|---|
| A generic IT/MSP platform (patching, RMM, laptop fleets) | The data model is AV operations. Your endpoint tooling stays where it is. |
| A general-purpose project tracker | Projects here assume rooms, equipment, partners, and visits. Marketing campaigns and software sprints are the wrong fit. |
| An enterprise ITSM replacement | The service and audit surface covers AV scope, not company-wide ticketing. |
| A monitoring probe | APEX surfaces manufacturer telemetry through connectors. It runs no synthetic checks of its own. |
| A CAD or drawing tool | Design files can live on a project, but APEX does not render or edit them. |
| A billing system | License costs and visit records are tracked; invoicing stays in your existing AR system. |
Where to go next
- Do a first guided pass through the product: Get started with APEX
- Look up who can do what: Roles and access
- See how the separation between Companies is enforced: Data isolation and security