For monitoring and operations partners

If you monitor buildings on behalf of customers, your constraints are different from an owner's. You are watching many buildings across several organisations, your team works in shifts, and your value is in catching things early and consistently. This article is about the parts of Properate built for that.

Work from organisation level, not building level

Opening buildings one at a time does not scale. The organisation-level views are the working surface:

• Organisation alarms — alarms for every building in the portfolio, filterable between all alarms and just your own. Select one to open its details and deviations.

• Organisation incidents — the triage queue. Filter by severity, and watch unassigned: on a shift handover, unassigned is the list that tells you what nobody has picked up.

• Organisation notes and tasks — for context and work that spans buildings rather than sitting inside one.

Incidents at organisation level, across the whole portfolio, with source and status.

Notes at organisation level, recording what was changed and over which period.

Make the alert volume survivable

This is the difference between a monitoring service that works and one that gets ignored.

• Alert groups — maintain the on-call rotation in one place instead of repeating names across every building's alert configuration.

• Notification throttling — when the same alarm fires repeatedly in a short time, the extra notifications collapse into one summary, while other alarms in the same setup still come through normally. On by default. At your volume this is the single most important setting: it is what stops one flapping sensor from hiding a real fault elsewhere.

• Response delay — on each alarm, require the deviation to persist before it triggers. Most false positives are transients during start-up.

• Anomaly monitoring — catches behaviour that no alarm covers, which matters when you onboard a building you did not commission and do not yet know well.

Standardise instead of rebuilding

The work you do once should apply across customers:

• Virtual sensors give you a consistent derived measure — an efficiency, a normalised figure — even where customers' metering differs.

• Cloud automations put your operating logic in one reviewable place rather than in each building's control system.

• Technical schemas can be copied across sub-buildings, and have a draft mode plus an audit trail of who changed what — worth having when several engineers maintain the same drawings.

• Task templates at organisation level make recurring service work identical across the portfolio.

• Shared widgets can be published and set as a default widget for specific roles — so you decide what a customer's caretaker sees on opening Properate, rather than hoping they build a useful dashboard.

Give customers visibility without risk

The Read-only role gives a customer access to dashboards and reports on their own buildings with no ability to change data or settings. Module settings control which modules appear per building and per organisation, so each customer sees what they have bought and nothing confusing beyond it.

Automated reporting turns your monitoring into a deliverable: scheduled reports for single buildings or whole portfolios, sent to the customer's recipients without anyone on your side remembering to produce them.

Step by step: the jobs you do most

Triage the morning across every customer

• Start at organisation level rather than opening buildings one at a time. Open Incidents from the organisation menu.
  

• Sort by Reported at to see what came in overnight.
  

• Filter by Severity to separate what needs a call from what needs a look. The Source column tells you whether it came from the building automation system or from an alarm you built.
  

• Work the unassigned items first. Anything assigned has an owner; anything unassigned is nobody's, and those are what get quietly forgotten.
  

• Open an incident and select Assign to me, or assign it to whoever is on shift.
  

An incident that resolved itself overnight is still worth reading. A value that leaves and returns on its own several times a week is a fault developing, not a non-event.

Create an alarm so the problem is caught next time

• Open Alarm configuration for the building and select New.
  

• Choose the Type. Beyond a simple threshold you can compare one timeseries against another — a supply temperature against its setpoint, for example — which catches drift that no fixed limit would.
  

• Set the condition: the limits, and the Direction if you are comparing two values.
  

• Set the deadband where offered. This is a range around the threshold that stops the alarm switching on and off while a value hovers at the limit, and it is the single most effective thing you can do to prevent noise.
  

• Use Delayed response so a momentary blip does not raise an incident.
  

• Set Severity and Category. Category is what lets you later write one alert configuration covering, say, every heating alarm across the portfolio.
  

• Decide whether Acknowledgement is required — on triggering, on resolving, or both. Require it where somebody must confirm they have seen it; leave it off where the record is enough.
  

• Select Create alarm.
  

Decide who gets told

• Open Alert groups and select Add group.
  

• Add the members. Give each a Priority, and choose whether they are notified by email, by phone, or both.
  

• Go to Alert configuration and create a new one.
  

• Select which alarms it covers. You can pick them individually, or query by severity and category — the latter keeps working as new alarms are added, which the former does not.
  

• Add a group rule to say which group is responsible, and when. Choose Notify all or Notify by priority, where the second person is only contacted if the first does not respond within the timeout.
  

• Add exception rules for the times you do not want to be called — and a fallback group so nothing lands nowhere.
  

An alarm without an alert configuration still records deviations. It just tells nobody, which is occasionally what you want and usually not.

Stop one flapping sensor burying everything else

• Open the alert configuration in question.
  

• Turn on Smart alert throttling.
  

If one alarm fires repeatedly over a short period, those notifications are grouped into a single summary. Other alarms in the same configuration are still delivered normally, so you are not trading noise for silence.

Build once, use across the whole portfolio

• Task templates. Create them at organisation level so the same service routine applies at every building instead of being retyped per site.
  

• Shared widgets. Build the monitoring dashboard once, share it, and use Set as default for roles so every operator opens the same view.
  

• Calculation flows. Use Make a copy on a virtual sensor or cloud automation that works, and point the copy at the next building rather than rebuilding the graph.
  

• Alert groups can be shared, so a rota is defined once rather than per building.
  

Give each customer their own view, safely

• Open User administration and select Create user.
  

• Set Role to Read-only.
  

• Under Select buildings, pick only that customer's buildings.
  

They see live data, dashboards and reports for their own buildings, and can change nothing. This is usually a better answer than emailing monthly summaries, and it costs you nothing to maintain.

Check a building is actually delivering data

• Hover a value to see the age of the last datapoint. This is the fastest way to tell a sensor reading an unwelcome number from one that stopped reporting a month ago.
  

• For anything derived, check when the calculation last ran. Calculation problems raise notifications on the calculation itself, not building alarms, so they can sit unnoticed.
  

• On calendars, use Run sync and confirm the change actually reached the installation.
  

Worth doing when you take on a building, and worth repeating after any building update — identifiers can change, which is the usual reason sensors disappear from a floor plan.

Access you need

Super is global administrator access to every organisation and building, and can manage settings and users across the whole platform — appropriate for your own operations leads. Admin gives full edit access limited to assigned organisations and buildings, which is usually the right level for engineers working a defined customer set.

Beyond monitoring

Where a customer's systems allow it, energy flexing connects technical systems to flexibility and reserve markets, adjusting consumption for short periods without a noticeable effect on tenants. For a monitoring partner this is a service line rather than a feature — see the Energy article for how measures and activations work.