Facility Management Guide

Facility records such as room tags, assets, inspection status, and open issues are host-application data. The NPM SDK provides the document, drawing-tool, and annotation APIs needed to link each record to a Canvas polygon annotation. Mount the viewer, wait for viewer.ready(), and open the floor plan before allowing space creation.

• Drawing tools
• Annotation events
• Annotation selection
• Annotation deletion

Create the Canvas boundary first, then create the linked facility record only after Canvas reports the annotation identifier. This prevents host records without a selectable boundary.

• 1Open the floor plan and subscribe to annotation created, selected, and deleted events.
• 2Enable the polygon tool only after the document is ready.
• 3Keep a pending-space state while the operator draws the boundary.
• 4Capture the created event guid and open the room metadata form.
• 5Save the host record with that guid as its immutable annotation link.
• 6Clear the drawing tool after save, cancel, or navigation away from the workflow.

Use the documented polygon drawing action. The tool result confirms whether Canvas accepted the mode request; the created event supplies the boundary identifier needed for a facility record. Do not generate a fallback annotation identifier when no created event arrives.

• viewer.tools.set({ action: "SHAPE_POLYGON", enabled: true, style })
• viewer.annotations.on("created", handleCreated)
• viewer.tools.set({ action: "SHAPE_POLYGON", enabled: false })
• viewer.tools.clear()

Persist a facility record in the host application or its backend with annotationGuid as the link to Canvas. Keep room metadata, assets, inspection information, issue references, and notes in that record rather than assuming Canvas annotation payload fields will hold the facility schema.

• Require a non-empty room tag and captured annotationGuid before the first save.
• Keep selected room state separate from pending unsaved boundary state.
• Treat the saved annotationGuid as the key for selection, visibility, and deletion synchronization.
• Validate area, capacity, dates, and issue references according to the host data model before persistence.

Canvas selection and room-list selection are two views of the same annotation link. Update host state from selected; when an operator chooses a saved room in the list, request the matching Canvas selection. Selection commands are fire-and-forget, so the selected event remains the confirmation point.

• viewer.annotations.on("selected", handleSelected)
• viewer.annotations.select({ guid: annotationGuid })
• viewer.annotations.unselect()

Deleting an annotation is fire-and-forget. Retain the linked facility record until deleted identifies the same guid, then either remove the record or mark it as requiring a new boundary according to the product policy.

• viewer.annotations.delete({ guid: annotationGuid })
• viewer.annotations.on("deleted", handleDeleted)
• If polygon-tool activation fails, do not enter pending-space state; retain the form inputs and offer retry.
• If a created event has no usable guid, clear pending state and do not save a room record.
• On metadata-form cancel, clear the tool and delete the unsaved boundary only after choosing an explicit product policy.
• Unsubscribe annotation listeners and destroy the viewer during route cleanup.

Test creating, selecting, cancelling, and deleting spaces against a real floor plan.

• Add Space stays disabled until the floor plan is ready.
• A room form opens only after a created event supplies a guid.
• A saved room record keeps the same annotation guid used by its Canvas boundary.
• Selecting from Canvas opens the matching host room record.
• Selecting from the host list is confirmed by the Canvas selected event.
• Deleting a boundary does not silently leave an orphaned room record.
• Route cleanup removes listeners and discards stale pending-space state.