Adapt SitePulse for operations
Use SitePulse’s location → signal → alert → response pattern as the starting point for a separate facilities app. This guide supplies a proposed brief and acceptance checks; it does not claim the facilities adaptation has already been built.
Before you begin
Follow Getting started with Builder MCP. Preview SitePulse Operations Dashboard – Native.
The recorded example mixes operational sample records with external feeds. Dates and status labels in a demonstration are not a verified assessment of a site. For your target, define the site inventory, source owners, operator roles and one response workflow.
1. Ask the agent to inspect the source
Review the actual source and bindings. A healthy-looking integration row is not sufficient evidence that a feed is configured and working.
2. Define one facilities response journey
Use a bounded initial path: an operator reviews an issue at a site, assigns a task, records progress and confirms completion.
Specify who may create, assign and close work. Decide whether closing a task also resolves an alert, whether completion needs evidence, and what should happen when the same issue is reported twice.
For each signal, document its source, units, timestamp meaning, acceptable age and failure behaviour. Keep observed conditions separate from recommendations and confirmed decisions.
3. Plan a separate target app
Record the target app ID and editor URL. Follow the current Builder MCP guide’s staged workflow. Review the target data model and permissions before wiring screens or connecting real sources.
4. Make freshness and ownership visible
Ask the agent to make the source and timestamp understandable beside a signal. A stale or failed source should have an explicit state. Agree what the operator can do next rather than defaulting missing information to “normal”.
Show the site context on an alert and its response task. Keep task ownership and lifecycle changes visible. Use synthetic events to exercise the workflow before enabling operational actions.
5. Test the complete path
Fresh reading
Correct units, source and timestamp are shown
Stale reading
Staleness is visible under the agreed policy
Missing or failed feed
A distinct unavailable state appears
Duplicate event
Handling follows the agreed duplicate policy
Task assignment
Correct site/alert context and authorised owner are retained
Completion
Required information is present and related state changes are correct
Restricted user
Other sites’ protected records and actions remain inaccessible
Mobile or keyboard use
Main review and response controls remain usable
Record the target build, scenarios, expected and observed results, role and screenshots. Validate thresholds with the business owner; the demo’s labels do not establish the target’s operating policy.
Troubleshooting
For an unexpected alert, inspect its source, unit conversion, timestamp and threshold before changing the rule. If a task appears at the wrong site, inspect the relationship IDs in the saved target records. If a source is unavailable, surface that failure rather than substituting an unexplained value.
Cost and rollout
Direct artifact edits can use the connected agent’s eligible allowance without Buzzy generation credits. External services may have their own costs or terms; API usage, Buzzy generation and deployment are separate. See AI usage and pricing.
Expand beyond the first site after the agreed scenarios pass. Follow the deployment publishing guide and repeat the relevant checks in the deployed target.
Explore the template series
Read the article overview or explore the complete Builder MCP template series.
Last updated