Skip to content
← All work

Building Operations Automation

Escala Residences — Water Sensor Automation

Production — in use and maintained

A production automation maintained by RTH Tech Services Inc. that converts building water-leak sensor emails into service requests within seconds and automatically closes matching requests when return-to-normal alerts arrive.

Before automation, leak alerts arrived as plain emails in a shared mailbox. Concierge and property-management staff had to read each message, identify location details, find contact information, and manually create service requests around the clock.

What it solves

  • Manual alert handling was slower and inconsistent during high-volume or after-hours periods.
  • Service request details depended on individual interpretation of plain-text sensor emails.
  • Closing resolved events required separate follow-up even when return-to-normal alerts were available.

Technology stack

Microsoft 365 shared mailboxPower AutomateBuilding water-leak sensor systemCondo ControlOperational loggingVersion-controlled scripts and documentation

My role

I designed, implemented, and maintain this production workflow through RTH Tech Services Inc.

Constraints

  • The parser depends on vendor email formatting.
  • Common-area sensors do not have resident contacts.
  • Units without a designated contact still generate a service request with a note.
  • The current configuration is property-specific.
  • Fallback depends on original mailbox alerts remaining available.

Highlights

Automated alert-to-request path

When a leak alert email arrives, the workflow parses device, location, unit, and alert time, records the event, looks up the affected unit/contact, and creates a pre-populated service request in seconds.

Automatic recovery closure

When a return-to-normal email arrives, the matching open service request is located and closed automatically with a note.

Exception and fallback handling

If any step cannot complete, designated on-call staff receive an exception email, while original mailbox alerts remain as the fallback record for manual processing.

No new concierge interface

Concierge continues working in the existing service-request queue and interface rather than learning a separate day-to-day tool.

Key decisions

Keep the operational queue unchanged

I integrated with the existing property-management request queue so operational adoption stays low-friction.

Preserve manual fallback by design

Original sensor emails remain in the shared mailbox, allowing staff to revert to the prior manual process without reconfiguration.

Alert flow

The workflow receives sensor email alerts, parses key fields, writes an operational-log entry, maps the event to resident-contact context where available, and opens a pre-populated service request for concierge follow-up.

Roadmap

Planned improvements include managed secret storage, stronger common-area labeling, more resilient operational-log reporting, scheduled parsing tests, and broader configuration parameterization.

Outcomes

  • Service requests are created within seconds of sensor alert emails.
  • Request formatting is consistent across alert events.
  • Resolved sensor events can be closed automatically when return-to-normal messages arrive.
  • Operational history is auditable through mailbox records, workflow run history, and the event log.
Have a similar problem to solve?
Let’s talk about what a practical solution would look like for your organization.
Discuss a project