Every question worth asking about a CMMS,
answered plainly.
Asset hierarchy, AI, federation, parts, QR durability, reports, integrations, security — the structural decisions behind Sympl, with comparisons to Limble, MaintainX, UpKeep, Fiix, and eMaint where the difference matters.
Contents
21 sections, ~104 questions
The asset hierarchy story
Asset hierarchy is the foundation of any CMMS. Work orders, PMs, criticality scoring, parts consumption, cost rollups, and reliability analysis all reference assets — and how those assets are modeled determines whether the answers are right. Most CMMS treat where as a single tree. Real maintenance has three answers.
Why is hierarchy the foundation, and what do most CMMS get wrong?+
Most CMMS ship a single parent-child tree and call it hierarchy. That works until the day a resident calls "no AC in apartment 101" — and the system says Apt 101 has no children, because the rooftop HVAC unit lives in a different branch of the tree (it serves six apartments; you had to pick one as its "home"). The tree is an org chart, not a wiring diagram, and a CMMS that only models the org chart is structurally incapable of routing maintenance correctly. Sympl models three independent relationships — containment, installation, and service — because that's what real facilities actually have.
Containment vs. installation vs. service — what's the difference?+
- Containment is where it lives in the org chart — Site → Building → Floor → Apartment, or Plant → Production Line → Equipment. A strict tree, used for navigation and reports that ask "what's in this building?"
- Installation is what position the equipment is mounted at right now. A pump goes to the rebuild bench, a replacement is installed, both pumps' histories survive — and the position itself accumulates a failure pattern. This is the "Functional Location" concept from SAP PM and Maximo, but without forcing customers to model two parallel trees from day one.
- Service is what this asset feeds, controls, or backs up. A roof HVAC unit serves six apartments. A backup generator backs up the fire pump and the IT closet. Typed, directional relationships between assets — serves, feeds, controls, depends-on, backs-up.
How is this different from Limble, MaintainX, UpKeep, and Fiix?+
How is this different from SAP PM and Maximo?+
SAP PM and Maximo handle the modeling — Functional Location plus Equipment as separate object types, with installation events between them. They get the data model right, and have for decades. The cost is that customers have to choose between FLOC and Equipment from day one, which ripples through onboarding, reporting, permissions, and integrations. We treat them as the same object with an optional installation field; the complexity only appears when the customer needs it. The result: a Maximo-grade reliability story without the Maximo onboarding curve.
How do you model an HVAC unit serving six apartments without picking a "home"?+
The HVAC unit is one asset. The apartments are six separate assets. We connect them with six service edges — one HVAC → Apt 101, → Apt 102, … → Apt 203. On the HVAC unit's detail page you see "Serves: Apt 101, Apt 102, …" On Apt 101's detail page you see "Served by: HVAC Unit, Boiler, Electrical Panel." Same edge, two surfaces. When a resident calls about Apt 101, the system suggests routing the work order against the HVAC unit and logs Apt 101 as an affected asset — so reporting can still answer "how many WOs affected Apt 101 this quarter."
What's position-level reliability, and why does it matter for pumps, RTUs, and motors?+
Rotating equipment moves. Pumps go to the bench for rebuilds. RTUs get swapped after compressor failures. When a pump physically swaps positions, you have two distinct lifecycles to preserve: the pump's history (every position it's lived in, every overhaul) and the position's history (every pump that's been mounted here, how long each lasted, what failed). Sympl tracks both via a separate install/dismantle event log. The payoff is the question only this model can answer: "this position has gone through 3 pumps in 5 years — is the failure pattern positional (cavitation, suction-side, environmental wear) or unit-specific?" Most CMMS can show a pump's PM history. Sympl can also show the position's failure pattern.
How does in-line asset swapping work?+
A 60-second mobile workflow: scan the QR on the failing asset, tap "Swap." The dismantle and the install are recorded in one transaction — the old pump moves to the spare pool marked in repair, the new pump (also scannable) installs at the same Functional Location, the work order that drove the swap stays linked to both. Both pumps' histories survive intact. The position's install/dismantle log gets one new event. The audit trail reflects the swap as one logical operation, not two separate edits a tech might forget the second half of.
Replacements work the same way — the only difference is the old asset is decommissioned at the end instead of returned to the spare pool. Same workflow, same atomic transaction, same link between the retired asset and its replacement.
Line history — "this pad has a 2× failure rate for pumps"+
Position-level history is the foundation, but the value is in the pattern across positions. The line-history view rolls up by Functional Location group: every pumping station on Cooling Water Loop 2, every roof RTU pad on Building B, every CIP skid on the brewhouse line. The question it answers is the one a reliability engineer actually asks:
"Why does Pumping Station A consume pumps at twice the rate of Pumping Station B, when they're identical specs from the same supplier?"
The answer is almost never "bad pumps." It's suction-side cavitation, an alignment problem, a vibration source, an environmental issue, a piping defect — none of which the pump itself can tell you, and none of which a unit-only history will surface. The line-history view shows mean position-uptime, swap frequency, and dominant failure modes per position, side-by-side across the line. The 2× outlier jumps off the page.
Do I have to model all three relationships up front?+
No. The model is additive. A new hub can register an asset with just a name and a kind. Containment alone gets you a working CMMS — work orders, PMs, parts, dashboards, all of it. Installation history and service edges are opt-in; they appear when you want them and stay invisible when you don't. There's no "phase 2 implementation" — the data model expects you to grow into it.
Spatial vs. physical assets
Two kinds of asset, two kinds of question. Both first-class.
What's the difference between a spatial asset and a physical asset?+
A spatial asset is a place — a site, building, floor, room, production line, pumping station, wet well, electrical room. A physical asset is a thing — a pump, an RTU, a motor, a chiller, a control panel. Spatial assets are mostly stable (the building doesn't move); physical assets often aren't (the pump goes to the bench). Both are first-class in Sympl with their own history, work orders, PMs, and fields — but the field set is different.
Why does spatial-vs-physical matter for fields, PMs, and reporting?+
A pump has a make, model, serial number, and lifecycle (in service → in repair → decommissioned). A pumping station doesn't — it's a position, not a piece of equipment. Forcing spatial assets to expose make/model/serial fields adds noise to every form and every export. Sympl hides those fields automatically when an asset is spatial. Reports that ask "MTBF by equipment class" naturally exclude spatial assets; reports that ask "WOs by location" naturally include them.
Can a spatial asset have its own work orders, PMs, and position history?+
Yes. A pumping station can have its own PMs (annual structural inspection of the wet well), its own WOs (a leak in the discharge piping that's not specific to the current pump), and — most importantly — its own position history showing every pump that's ever been mounted there. That's the surface where "is this a pump problem or a position problem?" gets answered.
How does this map to ISA-95?+
ISA-95 (IEC 62264) describes a manufacturing operations hierarchy: Enterprise → Site → Area → Work Center → Work Unit. Sympl's spatial primitives map directly. Site is a top-level spatial asset; Area, Line, Cell, and Equipment are spatial children. Physical assets (pumps, motors, valves) attach as installed equipment. Customers running a UNS already organized along ISA-95 lines see their topic tree mirror our hierarchy with no translation layer.
Open standards & taxonomies
Open standards in, open standards out. You're never locked into a vendor-flavored taxonomy.
Which industry standards do you align to?+
We seed every demo workspace with reference taxonomies that tag assets with codes from open standards. The current set:
- ISO 14224 — petroleum/process reliability data taxonomy.
- ISO 55000 / 55001 — asset management governance.
- ISA-95 / IEC 62264 — manufacturing operations hierarchy.
- UNIFORMAT II (ASTM E1557) — building element classification.
- OmniClass Tables 21/22/23 — construction classification.
- VMRS — fleet maintenance reporting (SAE / TMC).
- eCl@ss — international cross-industry product classification.
- NFPA 20 / 25 — fire-pump operational requirements.
- EN 15341 — maintenance KPI definitions; cited on every standard report.
What does "open standards in, open standards out" actually mean for my data?+
Two things. First, when you bring data in — from a Maximo export, a Fiix CSV, a Fleetio API pull — we map onto open codes (ISO 14224 equipment classes, VMRS fleet codes, etc.) rather than into a vendor-specific taxonomy you can't take with you. Second, when you take data out — via API, scheduled CSV, Snowflake export — those open codes go with you. You're never locked into a Sympl-specific taxonomy that needs translation if you switch tools.
How do failure codes work, and why ISO 14224 tagging on WO close?+
When a tech closes a corrective WO, we ask for a problem / cause / resolution triple drawn from ISO 14224 Annex B. Free text is fine for the description; the structured triple is what powers MTBF, MTTR, top-failure-mode Pareto charts, and replace-vs-repair signals. AI suggests the triple from the tech's free-text description; the tech accepts or corrects; the structured data flows downstream. This is the difference between "we have failure data" and "we have failure data we can report on."
Can I bring my own taxonomy or extend yours?+
Yes. The seeded taxonomies are starting points, not fences. You can add your own equipment classes, failure modes, or asset types alongside the seeded ones. Custom Types let you extend the catalog with your own field bundles — stamped with their own codes if you have them.
Service graphs in practice
Trees answer questions about structure. Graphs answer questions about flow and dependency.
What questions can a graph answer that a tree can't?+
- "If I take Cooling Tower A offline tomorrow, what gets warm?" — graph.
- "Show me everything in Building B." — tree.
- "This apartment has no AC — what serves it?" — graph.
- "What's on Production Line 2?" — tree.
- A tree alone cannot answer the graph questions correctly. Most CMMS try to fake it by overloading the parent field, which forces the modeler to pick one downstream consumer and remember the rest informally.
How does outage / impact preview work?+
Before you put an asset into in-repair status, the system surfaces every served-by asset that's affected — every apartment, every production line, every downstream space. No more "why didn't anyone tell me the chiller was down" surprises. The same lookup powers shutdown planning: a maintenance manager pre-scheduling chiller maintenance sees every space affected and reschedules to a low-occupancy window.
How does criticality inheritance flow through the graph?+
A chiller that serves an OR inherits the OR's criticality. A backup generator that backs up the fire pump inherits NFPA 20's response requirements. PM priority and response SLAs flow through the service graph automatically — no manual cross-referencing, no spreadsheet of "this asset is critical because it serves..." that goes stale the day someone reorganizes.
Smart WO routing — what does this unlock?+
When a resident calls about Apt 101, the system suggests the rooftop HVAC unit (it serves Apt 101 via a graph edge) instead of forcing the request against the apartment itself. The WO is routed against the HVAC unit, and Apt 101 is logged as an affected asset. Two payoffs: the tech routes to the actual cause, and reliability reporting can answer "how many WOs affected Apt 101 last quarter" even though every one of those WOs was technically against the HVAC unit. You get correct routing and correct reporting at the same time.
Work consolidation & efficiency
The hierarchy and service graph aren't reporting eye candy — they make scheduling smarter.
"While you're up there…" — can the system surface nearby WOs on the same line, panel, or roof?+
Yes. Because containment and the service graph are both first-class, the scheduler can group open WOs by site → building → floor → line, or by upstream service edge (everything fed by the same panel, served by the same roof RTU). The dispatcher sees "5 WOs on Roof RTU Pad #1 — schedule together?" instead of 5 individual line items.
Co-located WO grouping at scheduling time+
A tech going to Floor 2 to swap a thermostat shouldn't make a second trip for the burned-out fixture they could have carried up at the same time. The schedule board groups WOs by spatial proximity (same floor, same line, same panel) so the dispatcher can pack a route in one pass. The grouping isn't manual — it falls out of the hierarchy you've already modeled.
First-contact resolution tracking — return-trip detection+
Every corrective WO is checked: did a second corrective WO open on the same asset within 48 hours with a matching failure code? If yes, the WO is flagged as a return trip, and FCR rate appears on the dashboard and the asset detail page. FCR is one of the cleanest indicators of planning quality — return trips usually mean the tech showed up without the right part, the right tool, or the right diagnosis.
Reactive vs. preventive ratio — the maturity indicator+
A standard report shows the percentage of work that's corrective vs. preventive. Industry benchmarks put a mature program above 70% planned/preventive; the ratio is the single best maturity number a CMMS can report. We surface it on the home dashboard with an EN 15341 citation.
How is consolidation different from Limble, MaintainX, UpKeep, Fiix, eMaint?+
Job planning — why a planned job is 5–7× cheaper
A planned job is 5–7× less expensive to execute than an unplanned one. The time lost is not in the repair — it's in the three trips to the storeroom, the 45-minute hunt for a bearing puller, and the tech standing in front of the machine with no procedure and no spec.
The three-trips-to-the-storeroom problem+
A typical unplanned corrective: tech goes to the asset, diagnoses, walks to the storeroom, doesn't have the part, walks back, gets the wrong substitute, walks back again. Three round-trips to a far-away storeroom can eat 90 minutes on a 20-minute job. A planned job has the parts kitted and staged before the tech ever leaves the bench.
Pre-WO planning — parts, tools, procedure, time+
When a planner promotes a request to a WO, they fill in: required parts (reserved against inventory), required tools (checked against availability), the procedure (a task list, often pulled from the asset type's maintenance BoM), estimated minutes, and any required permits. The tech receives a WO that has everything they need — or, if anything is short, the WO won't release to scheduled until the planner closes the gap.
Permit-to-work for hot-work, confined-space, lockout-tagout+
WO types can require specific permit attachments before the WO can move to in-progress. A WO against a medium-voltage panel requires a lockout/tagout checklist; a confined-space WO requires the entry permit. The system enforces it; the tech doesn't have to remember.
What you save when the tech arrives once with everything they need+
The composite payoff: 30–50% reduction in wrench time loss (per IDCON and Factory AI studies), measurable as a drop in MTTR and a rise in PM compliance. We surface those numbers on the dashboard so the program improvement is visible in the data, not just felt on the floor.
Parts, kitting, and mobile inventory
The wrench-time differentiator most CMMS underbuild.
What's a kit, and how is it different from a maintenance BoM?+
- A kit is a part-catalog entry that explodes into individual stockable components at planning time. "Oil Change Kit" = 5 qt oil + 1 filter + 1 drain plug washer. Kits are operational shorthand: add the kit to the WO; the components reserve and pick as a unit.
- A maintenance BoM (mBoM) is a structured, type-level parts list attached to an asset type, with the ability to override at the individual asset level. The Boiler type's mBoM lists the parts a typical boiler PM consumes — the planner pulls from it.
- Kits are pick-as-a-unit conveniences; mBoMs are reference data that informs planning. Both ship.
Why is a tech's van a first-class parts location?+
A tech's van isn't a theoretical concept — it's where parts physically are when the tech is in the field. Sympl treats it as a first-class stock location: morning loadout is a normal transfer from "Main Storeroom" to "Tech Van #3"; issuing a part from the van to a WO is a normal issue transaction; and end-of-shift reconciliation is a quick count cycle. No parallel tracking system, no spreadsheet, no "where did that part actually go?"
Van-to-van transfers when the part is on someone else's truck+
A tech finds they need a part that's not on their van but another tech 10 minutes away has one. That's a van-to-van transfer — same mechanic as a transfer between sites. Both vans' inventories stay accurate; the transaction is auditable.
End-of-shift van reconciliation+
A guided count flow at end of shift: scan or click through van inventory, mark counts, reconcile differences, capture variance reasons. The variance feeds back into inventory accuracy reporting so van shrinkage is visible, not invisible.
In-transit inventory — what happens to $50k of parts on a truck in an accident+
When a transfer is initiated, the inventory doesn't atomically vanish from the source and appear at the destination — there's a real-world gap. Sympl models an "in transit" virtual location that captures the limbo state. If a truck is in an accident with $50k of parts on it, that inventory isn't at either site — it's still trackable as a known quantity. When the transfer is received, the in-transit balance drains to zero. Insurance, audit, and operational reality all stay coherent.
How do kits explode onto a WO at planning time?+
Add an "Oil Change Kit" to a WO; the kit explodes into its component lines (5 qt oil, 1 filter, 1 drain plug washer), each with their own reserve / pick / issue / return lifecycle. The WO shows which lines came from a kit ("From: Oil Change Kit") vs. individually added. At close, kit-level consumption is reported correctly even if components were substituted or returned.
Reserve → Pick → Issue → Return+
The four-step lifecycle that keeps inventory honest:
- Reserve — when the WO is planned, parts are earmarked. Other planners see the reservation; the count's "available" balance reflects it.
- Pick — storeroom worker physically pulls the parts and stages them.
- Issue — tech consumes the part on the WO; balance decrements.
- Return — anything unused goes back; balance increments.
Most CMMS skip "pick" and conflate reserve with issue, which means the inventory count is wrong from the moment a part is reserved until the WO closes. We model the four phases explicitly.
How is parts handling different from Limble, MaintainX, UpKeep, Fiix, eMaint?+
The industry-wide weak spot is mobile inventory. Limble, MaintainX, and UpKeep treat the storeroom as the inventory location and a tech's van as a logistical afterthought — a tag on a transfer at best. Fiix and eMaint do better but still typically model van inventory as a sub-storeroom rather than a first-class location with its own count cycle. Maximo handles it well, but at Maximo's onboarding cost. Sympl ships the mobile van as a stock-location type with the full transfer / issue / count machinery, plus the in-transit virtual location that none of them model.
The kitting story has a similar gap. Most mid-market CMMS treat a "kit" as a saved parts list — a planning convenience, not an inventory primitive. Sympl's kits explode at planning time into component reservations, retain kit identity through reserve/pick/issue/return, and report kit-level consumption correctly even when components were substituted. That's the 20–30% wrench-time gain IDCON and Factory AI cite, captured as a real workflow rather than a spreadsheet.
Sister platforms, accounts, hubs, federation
Account > hub > site. One person, many hubs. Networks for governed multi-hub setups.
What are SymplCMMS, SymplProject, and SymplSignal — and how do they relate?+
Three sibling products on one shared platform. SymplCMMS — maintenance management. SymplProject — capital project management for owners and GCs. SymplSignal — pre-bid intelligence for GC business development. Sibling, not stacked. Each product has its own webapp, its own data model, and its own buyer. They share platform infrastructure (single sign-on, permissions, audit log, AI gateway, event bus, storage) but have no direct dependencies on each other.
Account vs. hub vs. site — what models what?+
- Account — billing entity, owns one or more hubs. "ACME Corp" is one account.
- Hub — an isolated workspace with its own data, users, and configuration. "ACME East Plant" and "ACME West Plant" are two hubs under the ACME account. Each hub's data is isolated from every other hub.
- Site — a location inside a hub. ACME East Plant is one hub; the four buildings on that plant are four sites. Hub-level settings (industry, default locale) flow down to sites; site-level settings override (timezone, address).
One person, many hubs — how does that login work?+
A user has a single global identity and zero or more memberships in hubs. After login, users with more than one membership see a hub picker; pick one, you're in that hub's workspace. Switching hubs returns to the picker — sessions are bound to one hub, so cross-hub work happens via API keys or the rollup layer, not via cross-hub sessions.
What's a Network (federated hubs) and who's it for?+
A Network is a set of related hubs under one account where a parent entity has governance authority — corporate HQ overseeing business units, an MSP overseeing client hubs, a franchisor overseeing franchisees, a regional authority overseeing operating companies. The network portal is the parent's governance surface: cross-hub rollup KPIs, master catalog management, policy library, compliance scoring. Explicitly not an operational tool — no work orders to assign, no daily queue. The people using it check in periodically; when they do, they want exceptions, not a task inbox.
What can a parent push down — vendors, PMs, policies, locked fields?+
The catalog inheritance engine pushes data down (vendors, equipment classes, PM templates, failure modes); the policy library pushes standards down (PM mandates, vendor approvals, safety requirements, document requirements, data-quality thresholds, access policies). Each catalog row can have locked fields — fields the child can't override. A parent says "every centrifugal pump must have a PM at ≤ 90-day intervals," and the system checks that nightly across every child hub.
What does the child hub see, and can they override?+
Children are not passive recipients. The child sees a "Network standards" page listing every policy that applies, its enforcement level, and current compliance status. Inherited catalog rows show a "From network" badge; locked fields render with a lock icon. Compliance gaps trigger notifications to the child hub's admin: "Your network requires all medium-voltage assets to have an active PM ≤ 90 days. You have 4 assets with no qualifying PM." There is no silent enforcement.
Tracked vs. Enforced compliance+
- Informational — the parent publishes a standard. No measurement, no enforcement.
- Tracked — compliance is measured nightly; parent sees scores; child admins are notified of gaps. No UI lockout in the child. Good default.
- Enforced — the child cannot deviate. Locked fields are read-only; mandatory PMs can't be deleted; blocked vendors can't be unblocked.
How is federation different from Limble, MaintainX, UpKeep, Fiix, eMaint?+
AI — bring your own key, bring your own agent
Three goals, hard discipline. Plus an MCP server, BYOK, and grounded citations.
What's your AI philosophy?+
Three goals, hard discipline. Every AI feature in the product must achieve at least one of:
- Save the user time.
- Save the user money.
- Make the user smarter / more informed.
If a feature doesn't clearly map to one of these, it doesn't ship. We don't do "ask AI anything!" tiles, we don't summarize 3-line WO descriptions, and we don't generate content that has structured-input alternatives.
Can I bring my own AI provider / API key?+
Yes. AI configuration is managed centrally per hub. Customers on the BYOK tier point us at their own provider — Anthropic, OpenAI, Azure OpenAI, AWS Bedrock, or self-hosted Ollama — and supply the key. We use that key for that hub's inference calls; the bill goes to your account. For hubs that don't want to manage providers themselves, Sympl-managed inference is the default (a vision model for classification, Claude on Bedrock for grounded reasoning).
What's the MCP server, and what can I do with it from Claude / Cursor?+
We expose the CMMS API as a Model Context Protocol server so customers can connect Claude Desktop, Cursor, or their own agent tooling directly to their hub data with natural language. A reliability engineer can ask Claude "find me the pumps that failed within 90 days of installation across all sites, with the supplier names" — and Claude executes the right API calls against your hub. Same login, same permissions, same audit trail; every MCP-driven action is logged with the connected tool's identity. We don't host your agent; we host the connection point.
Is my data used to train shared models?+
No. Per-hub data isolation is absolute. AI features run with the active hub's data only. We never mix data across hubs for training or inference unless the hub explicitly opts into a benchmark or anonymized program — and even then, individual records never leak. This rules out a single fine-tuned model across all customers' data without consent.
How do citations and grounding work?+
No AI output without traceability. If the system says "this asset's PM frequency could be relaxed," you can click to see the WOs and time series the recommendation is based on. If it can't show its work, it doesn't ship. For document Q&A, answers cite the specific document and page. If the source doesn't contain the answer, the system says "this isn't in your documents" — never fabricates.
Does AI ever take a state-changing action without a human in the loop?+
No, by default. AI suggests; human commits. AI can pre-fill a form, propose a status change, or draft a notification — but a human clicks the button. Exceptions are explicit, scoped, opt-in, and audit-logged. When an AI suggestion influenced a record, the audit log captures it: which user committed it, which model suggested it, the confidence, and the citations used.
How is AI different from Limble, MaintainX, UpKeep, Fiix, eMaint?+
The mid-market category has converged on a single pattern: an AI chat panel grafted onto the side of the UI that summarizes WOs, drafts work descriptions, or suggests next steps. The structural limit is the same in every case: the AI is a feature bolted onto a UI-first product, so it can only act through the seams the UI exposes — and it acts on prompts the customer can't ground or audit at the field level.
Sympl's AI rides on top of an API-first architecture with a typed catalog. That's the difference between an LLM that can hallucinate a field name and one that has a closed schema to produce against. It's also why we ship an MCP server: the customer's own Claude / Cursor / agent connects directly to their hub data, executes against the real API, and the audit log captures every action. BYOK (bring your own AI key, your own provider, your own bill) is the same idea applied to inference economics: customers with bulk Anthropic or Bedrock contracts shouldn't pay our markup. Provider and model are vendor-locked everywhere else in the category.
Documents — classification, extraction, finding manuals
Drop a folder of PDFs; the system reads them.
What happens when I drop a PDF into the system?+
Every PDF goes through a classification pipeline: render the first 3 pages, send the page images to a vision model, extract document type, manufacturer, model identifiers, revision, and a confidence score. The result populates the file metadata and surfaces a cover image preview. About 22 document types are recognized today: operations manual, service manual, parts catalog, installation guide, technical specification, floor plan, drawing/schematic, quick reference, service bulletin, SDS, compliance document, risk assessment, SOP, training material, inspection report, calibration certificate, maintenance log, PM schedule, warranty document, purchase order, invoice, and unknown.
Can the AI extract PM templates from an OEM manual?+
Yes. Drop an OEM manual onto an asset; the extraction pipeline reads the maintenance section and proposes draft PM templates with intervals, task lists, and required parts. The planner reviews the drafts in a side-by-side view (extracted text + proposed PM) and accepts, edits, or rejects. The extraction includes citations back to the source page.
Can it find a manual online for me?+
Type "Trane RTU XR12" or paste a photo of a nameplate; the system extracts make/model/serial, matches the equipment class, and surfaces the manufacturer's manual when it's findable. The agent has access to manufacturer documentation sources and falls back gracefully when nothing's available.
What about drawings, schematics, SDS, calibration certificates?+
All recognized document types. Drawings and schematics get pinned to assets with the same edge-typed model as floor plans; SDS sheets get pinned to chemicals/parts and surface in WO contexts that involve them; calibration certificates and inspection reports attach to the relevant asset with their own expiration tracking and renewal reminders.
Floor plans
Pin assets to a floor plan; click on the plan to navigate.
What can I do with floor plans?+
Upload a PDF floor plan; the system classifies it as a floor plan, renders pages, and stores a high-resolution viewable. From there, you pin assets to coordinates on the plan — clicking an asset on the floor plan jumps to its detail page; clicking an asset's location on its detail page highlights it on the floor plan.
How does PDF floor-plan upload + classification work?+
PDFs go through the same classifier as other documents but with a specialized post-processing path: the page images are persisted at full fidelity (so they're zoomable in the UI), the classifier confirms the document is a floor plan (not, say, a P&ID misfiled as one), and the result becomes a navigable spatial layer attached to a building or floor. Image floor plans (PNG, JPG) skip the classifier and go straight to the spatial layer.
Can I pin assets to a floor plan?+
Yes. Drag-and-drop pinning, with the pin coordinates stored as part of the asset's spatial relationship. A floor's detail page shows the floor plan with every pinned asset visible; an asset's detail page shows the floor plan zoomed to the asset's location. Overlays — WO-density heatmaps, criticality coloring, open-WO badges — render directly on the plan.
Floor plans as spatial assets vs. as documents+
Both, simultaneously. The floor plan is a document (classified, stored, audited like any other PDF) and the floor it represents is a spatial asset (in the hierarchy, navigable, with its own work orders and PMs). The document is attached to the spatial asset; the spatial asset is the queryable primitive. This way, "what floor plans does Building B have?" and "what's on Floor 2?" are two different questions with two different answers, both correct.
QR codes — durability and label longevity
The QR you stick on a chiller in 2026 still works in 2036, regardless of how the URL space evolves.
Why won't reprinting be a problem if I rebrand, change regions, or change URL conventions?+
Every QR code printed on physical equipment encodes a stable URL on a single global redirector — qr.symplone.com — that forwards to whatever the current canonical destination is. The redirect target is configurable. If you rebrand, change subdomain conventions, migrate a hub between regions, or change the asset URL shape — one bulk update re-points every label in the world. We've seen vendors change URL schemes and force customers to reprint hundreds of laminated labels. The redirector exists specifically to make that impossible for us.
What's printed on the label besides the QR?+
- Asset name (large, human-scannable).
- Tag (e.g. EQ-00266) — the human-readable backup if the QR is unreadable.
- Site code (e.g. AUS) — for multi-site staff.
- Optional: criticality letter, type code, or a "report a problem" URL for public-facing signage.
Sizes for indoor vs. outdoor / high-bay?+
- 2.5cm × 2.5cm — default; survives indoor environments and reads from arms-length on a phone.
- 5cm × 5cm — outdoor / high-bay equipment, reads from a few meters away.
- Configurable per print template.
Can the same QR work on the web and deep-link into the mobile app?+
Yes. Universal Links (iOS) and App Links (Android) registered on qr.symplone.com route the URL into the installed app instead of the browser. Same QR, no re-issuance.
What about NFC fallback for harsh environments?+
For environments where laminated QRs don't survive (high-temperature, chemical, abrasive), an NFC tag stores the same redirector URL — same destination, same code, no UI change.
How is QR durability different from Limble, MaintainX, UpKeep, Fiix, eMaint?+
Templates and types — extending without forking-and-breaking
Three concepts, three names, three roles. No conflation.
Type vs. instantiation template vs. PM template+
- Type — a typing overlay applied to existing entities. The "Boiler" type, when applied, activates fields like BTU rating, pressure rating, ASME stamp, and fuel type, links default PMs, and scopes the failure-mode picker.
- Instantiation template — a starter for creating new entities quickly with defaults pre-filled.
- PM template — a recurring-work generator. Distinct from one-shot WO templates and from Types.
How do I extend (fork) an industry-preset template without losing future updates?+
Master-data inheritance. When you customize an industry-preset Type, the parent fields stay live — your child overrides are tracked field by field. Fields you haven't touched continue to receive parent updates. Fields the parent has marked as locked can't be overridden at all. So you fork what you need to fork, keep inheritance on everything else, and don't lose the next preset improvement. This is the model used by package managers and language ecosystems; we apply it to CMMS reference data.
Custom fields scoped to a Type+
A custom field can scope to a Type. Boiler-only fields show up only on assets with the Boiler type applied; reports filter automatically. Fields can also scope to asset kinds, sites, or be global.
Industry presets — pre-built types per vertical+
We ship pre-built Types per vertical: chemical manufacturing → Reactor, Distillation Column, Heat Exchanger; multi-family residential → Apartment, Common Area, Roof Equipment; water utilities → Pumping Station, Treatment Train, Disinfection Bank. Each preset bundles the fields, default PMs, and failure-mode subsets that vertical actually uses. New customers pick a preset at onboarding and start in week one with the structure their domain needs.
How is template extension different from Limble, MaintainX, UpKeep, Fiix, eMaint?+
Custom fields & extensibility
Per-hub flexibility and report-grade performance, both at once.
How do custom fields work — searchable, reportable+
Custom fields are first-class on every extendable entity (assets, work orders, sites, locations, parts, vendors). Field definitions are managed per-hub via the admin UI: name, data type (text, number, date, datetime, boolean, single-select, multi-select, user reference, asset reference), required/optional, default value, options list. Fields marked searchable appear in the global search index; fields marked reportable are indexed for reporting automatically, so report queries against them stay fast even at millions of rows.
Type-scoped vs. kind-scoped vs. global+
A field's scope controls visibility. No scope = applies to all entities of the entity type. Scoped to fleet = only fleet assets. Scoped to a Type = only assets with that Type applied. Scopes can combine.
Why is this fast at scale?+
The classic CMMS pain point with custom fields is that they're stored in a slow, untyped sidecar table — querying a custom field across a million-asset workspace crawls. Sympl stores custom fields in typed structures with per-hub indexes, so reports and filters run at the same speed as the built-in fields. No schema migration when you add a field; no crawl when you report against it.
Reports & report scheduling
~21 standard reports, EN 15341 / ISO 14224 grounded. No tarpit report builder.
What reports do you ship?+
About 21 standard reports, drawn from EN 15341 (KPI definitions) and ISO 14224 (reliability). Each report cites its standard reference. Categories:
- Reliability & maintenance KPIs — PM Compliance, Schedule Compliance, WO Throughput, Backlog Aging, MTBF, MTTR, Asset Availability, Top Failing Assets (Pareto), Top Failure Modes (Pareto), Reactive vs. Preventive Ratio.
- Cost & financial — Maintenance Cost per Asset, Maintenance Cost Ratio, Cost Trends, Replace-vs-Repair Candidates.
- Workforce — Technician Productivity, Labor Allocation, Skills & Certification Status.
- Compliance & risk — Criticality Assessment Coverage, Compliance Program Status.
- Operational — Inventory Turnover & Stockouts.
- Performance management — KPI Scorecard.
Why no custom report builder?+
Custom report builders are a tarpit. Customers ask for them; vendors build them; they consume product engineering for years and never satisfy power users (who use real BI tools anyway) or simple users (who want one-click answers, not a query designer). Better discipline: ~21 well-built standard reports + an excellent API + scheduled exports → your BI tool. New reports require retiring or merging an existing one.
Schedule a report to email weekly+
Each report has a "Schedule" action: pick recipients, cadence (daily/weekly/monthly/quarterly), format (CSV/Excel/PDF), and filters. The notifications service delivers; recipients see the version filtered to their scope (not the senders' scope) so a regional VP gets their region's data even if the schedule was set up by the corporate FM.
Export to Snowflake, BigQuery, Redshift+
Hub Admins can configure scheduled CSV or Parquet exports to S3 (we write directly with your credentials), email, SFTP, or your data warehouse via standard ELT connectors. We don't compete with Tableau / PowerBI / Looker / Sigma — we make ourselves an excellent data source.
Drill from chart segment to underlying WOs+
Every chart segment, table row, and Pareto bar is drillable. Click it, you land on the underlying entity list (WOs, assets, parts) filtered to exactly that slice.
How is reporting different from Limble, MaintainX, UpKeep, Fiix, eMaint?+
Standards-grounded KPIs. Most mid-market CMMS define KPIs vendor-flavored ("our PM compliance metric"). Sympl's KPIs cite EN 15341 and ISO 14224 explicitly — formula visible, standard reference shown, comparable across organizations and auditable in regulated industries.
The report-builder discipline. Limble, MaintainX, UpKeep, Fiix, and eMaint all ship some form of custom report builder. They've spent years on it; their power users still leave for Tableau. We deliberately don't, and instead invest in a tighter standard catalog, full API + GraphQL, and scheduled exports to your data warehouse.
Custom dashboards
Reports are the source of truth; widgets are projections of them. ~75 widgets at v1.
Per-user dashboards from a widget gallery+
Every report contributes one widget per supported surface (tile, trend, breakdown, Pareto, list, table, scorecard) — about 75 widgets at the v1 catalog size. The widget gallery is generated from the report catalog; there's no parallel widget registry, so reports and widgets never drift.
Hub-pinned default dashboards+
A Hub Admin can pin a dashboard for the hub or per role (Maintenance Manager sees PM Compliance + Backlog + MTBF; Technician sees My WOs + My Time This Week). Sites can have their own dashboards.
Why is the dashboard "panoramic" instead of obeying the site filter?+
The dashboard's job is comparison: site × site, team-wide trends, the "where do I look first?" question. Narrowing it to one site with the breadcrumb's site filter would reduce it to a one-tile view, which the per-site detail page already does better. The dashboard intentionally renders across the user's full site scope; the site filter narrows other pages — assets, work orders, requests — but not the dashboard.
KPI Scorecard — set targets, get notified on breach+
A KPI is a tile widget plus a target. Hub admins define KPIs against the standard reports — PM Compliance ≥ 90%, Schedule Compliance ≥ 85%, Reactive Ratio ≤ 25% — set targets and warn thresholds, and pick a period. The KPI Scorecard report aggregates them in one grid; a notification fires when a KPI crosses a threshold.
API-first, keys, and service accounts
The API is the product. Keys are scoped, intersected, and audited.
Is everything available via API?+
Yes. Every entity is queryable via REST + GraphQL with filtering, sorting, cursor pagination, and modified-since semantics. Every state change is a write API. Every event is published to webhooks and the internal event bus. The OpenAPI spec is the source of truth; the MCP server is generated from it; new endpoints automatically become MCP tools.
How do API keys work — per-user vs. service account?+
An API token is tied to either a person or a service account. Both go through the same permission engine. A token can be narrower than the user or service account behind it, but never broader — a token never grants more access than its owner has. Three patterns:
- User-bound token — issued by a developer for their own personal use. Inherits the user's role grants and scope. Revoked when the user leaves.
- Service account token — issued for a non-human identity (an integration, a CI/CD pipeline, a vendor system). Service accounts have their own role grants, their own scope, and their own audit trail — they outlive any individual person. Default for any production integration.
- MCP token — bound to either a user or, preferred, a dedicated service account ("Mike's Claude Assistant") with its own role grants for clean audit separation. Every MCP-driven call is logged with the connected tool's identity.
Token scoping — what can be narrowed?+
- Permissions — a subset of the owner's effective permissions. "This token can read assets and create WOs, but not delete them, even though I can."
- Scope — a subset of the owner's scope. "This token only acts within Site = Atlanta Plant."
- IP allowlist (optional) — restrict to known networks.
- Expiration — every token has one; rotation is the norm.
- Tokens are validated at issue: if you try to declare a permission you don't have, the request fails. A leaked token can't do anything its scope didn't allow — and revoking the user or service account revokes every token under it.
Service accounts as first-class identities+
Service accounts have the same role/scope/ceiling machinery as humans. They just can't log in to the UI. You grant a service account roles in the admin UI, scope it to specific sites or asset classes, and issue it a token. Its actions show in the audit log distinctly from human activity, so you can see exactly what every integration did.
Webhooks and the event bus+
Every domain event (WO created, asset state changed, PM materialized, threshold breached, etc.) is published to the internal event bus. Hubs subscribe via webhook to deliver those events to their own systems — MES dashboards, Slack channels, ERP queues. Webhook deliveries are signed, retried with backoff, and observable in the admin UI.
How is the API and key model different from Limble, MaintainX, UpKeep, Fiix, eMaint?+
API coverage and key sophistication are the cleanest dividing lines in the category.
- Limble, UpKeep, eMaint typically ship a single workspace-wide API key — one key, full permissions, no scope. Anyone with the key can do anything. Rotating it is disruptive.
- MaintainX, Fiix offer per-user tokens with broader permission control, but typically without scope narrowing or per-token IP allowlisting.
- None ship a permission model where service accounts are first-class identities with their own role grants and scope, distinct from any human user.
- None ship an MCP server. Connecting your own Claude or Cursor agent to your hub data with natural language requires us — today.
Integrations & system of record
Who owns what data, modeled explicitly.
Who owns the data when I integrate with NetSuite, Workday, Geotab?+
For every entity type, exactly one system is the System of Record — the authoritative source. Other systems are replicas that may sync from it but cannot override it. SoR is declared per hub per entity type. For a customer with NetSuite, vendors are usually external SoR (NetSuite-owned); for one without, vendors are internal SoR (we own them). The declaration drives UI affordances ("managed by NetSuite — edit there"), API permissions, and conflict resolution.
The three SoR shapes+
- Internal — we are the SoR. Default for crawl. Examples: work orders, PM templates, criticality assessments, audit log.
- External (full) — another system is SoR for the entity. Our copy is read-only; UI shows a "managed by NetSuite" badge.
- External (field-level) — another system owns some fields; we own the rest. NetSuite owns vendor name, tax ID, and address; we own preferred tech contact, internal rating, and custom fields.
Procurement modes when the ERP owns POs+
- Sympl-owned — Sympl creates POs and mirrors them outward.
- ERP-owned POs — ERP owns POs; Sympl imports them and captures maintenance-side receiving.
- Request-only — Sympl creates purchase requests / reorder signals; ERP creates the PO.
- ERP-owned procure-to-pay — ERP owns procure-to-pay and inventory valuation; Sympl consumes the state.
Are you a UNS broker?+
No. Brokers and historians are dedicated infrastructure (HiveMQ, EMQX, AWS IoT Core, Azure IoT Hub, Mosquitto). We are a first-class UNS citizen: we subscribe to telemetry topics (drives meter readings, condition-based PMs, alarm-triggered work orders) and we publish WO lifecycle events back to the namespace so dashboards, MES, and scheduling can react. ISA-95 topic structures map directly onto our spatial hierarchy.
Multi-hub, security, audit
Per-hub data isolation. Audit on every change. Hard ceilings, not soft suggestions.
How is one hub isolated from another?+
Every hub gets its own isolated data store inside the platform — no shared columns that have to be filtered correctly on every query. Cross-hub data leakage is structurally impossible at the storage layer. Migrations roll out to every hub automatically. The benefit is data isolation that doesn't depend on application code being correct.
Audit log on every state change+
Every state change writes to the audit log via a single central writer. The log captures actor (user or service account), action, entity type and ID, before/after values, request ID, and (where applicable) AI involvement. Immutable from the application; only a database superuser can delete rows.
Permission model — roles, scopes, member-type ceiling+
Effective permissions are the intersection of role grants, direct grants, and a hard member-type ceiling. Roles bundle permissions. Scope narrows where the permission applies — by site, by asset class, or by other attributes you choose.
Why contractors can never escalate to admin+
Every user or service account has a member type — employee, contractor, vendor, etc. The member type is a ceiling: regardless of which roles a contractor is granted, contractors can never have admin-level permissions. A bug in role assignment can't create an escalation path. Hard rule enforced at the permission engine, not a soft suggestion in the UI.
Mobile & field work
Scanner-first, offline-capable, swap-aware.
What does mobile cover?+
- Asset swap — a 60-second mobile workflow that records dismantle + install in one transaction, preserving both pumps' histories.
- WO execution — open WOs, complete tasks, log time, capture photos, issue parts from the van, capture failure codes at close.
- QR scan → quick actions — scan an asset, get a context menu (Create WO / Log reading / Mark this WO complete on the right asset).
- Offline — operations queue locally and sync when connectivity returns.
Deep-linking from QR into the app+
Same QR codes work across web and mobile. When the app is installed, the OS's Universal Links / App Links route QR scans directly into the app — no browser flash, no re-issuance of QR codes when the app launches.
Onboarding, data, lock-in
Customers don't hand us a clean CSV. They hand us a folder.
Bulk-import from a folder of mixed files+
Customers don't hand us a clean CSV. They hand us a folder: 3 versions of an asset list (Excel), 80 PDFs of OEM manuals, photos of equipment nameplates, an old CMMS export, vendor contact lists in Word, scanned paperwork, maintenance procedures, a price list as a PDF. The onboarding agent processes the whole folder: filename heuristics for cheap classification, vision AI for ambiguous files, deep AI extraction for high-value items. Output: a draft asset list, draft PM templates, matched manuals attached to assets, a review UI for low-confidence items, and a documentation pack of what was preserved and what wasn't.
Extracting PM templates from a folder of OEM manuals+
Drop a folder of OEM PDFs; the system classifies, extracts manufacturer + model from the title pages, matches to your asset list, and proposes PM templates from the maintenance sections of the matched manuals. Each proposed PM cites its source page. The planner reviews in a side-by-side, accepts or edits, and the templates are live. This is the difference between "we can attach a PDF to an asset" and "we can convert your OEM manuals into a working PM program."
How do I export my data if I leave?+
Every entity is queryable via REST + GraphQL with cursor pagination. Hub Admins can configure scheduled CSV/Parquet exports to your S3 bucket, email, SFTP, or your data warehouse. Audit logs export. Documents export with their original filenames. Open-standard taxonomies (ISO 14224, VMRS, UNIFORMAT II) come with the data; you're not exporting a Sympl-flavored dialect that needs translation. The discipline behind "open standards in, open standards out" is exactly so the export-to-leave story is straightforward — even though we'd rather you didn't.
Still have questions?
The fastest way to evaluate is a 30-minute demo against your own data. Bring real workflows; we'll show you what onboarding looks like in real time.