Your IoT platform should respect the structure your business already has. With Blynk's Custom Databases, you can model hierarchies, reference data, and device context inside the platform, instead of maintaining them separately.
Most businesses have a structure that predates their IoT projects. Customers, projects, sites, assets, schedules. Your team knows how these things connect. Your processes depend on it.
IoT platforms handle device data well. What they don't handle is the business data that gives device data meaning: product specifications, rental agreements, maintenance schedules, project hierarchies. That context ends up in spreadsheets, CRMs, or project management tools.
This creates friction in daily operations, not just troubleshooting. Tracking which devices are deployed where, what context they're operating in, what reference data applies to them. As deployments scale, that friction compounds.
Custom Databases let you extend Blynk's data model to match your actual business structure: custom fields, relationships between records, and reference data that has nothing to do with devices.
The pattern is consistent across industries. Businesses have hierarchies and relationships that matter. IoT projects work better when they fit inside that existing logic.
HVACR service companies manage complexity across multiple dimensions: clients, sites, equipment units, maintenance schedules, and the technicians who keep it all running.
A typical structure looks like this:
Each unit has specs that matter during service: serial number, refrigerant type, tonnage, filter sizes, belt specifications, electrical ratings. Each service visit generates data: maintenance checklists completed, refrigerant readings, electrical measurements, parts replaced, issues found.
When a technician arrives on site, they need more than a work order. They need the unit's history, its equipment specs, and the standardised procedures that apply. When discharge temps run high or refrigerant pressure drops, the office needs to trace back: who serviced it last, what readings were taken, what parts were used.
With Custom Databases, the hierarchy exists inside the platform:
The mobile app walks technicians through multi-step service workflows. A PM visit might include visual inspections, a system checklist (coil cleaning, belt tension, electrical connections), and performance measurements like superheat, subcool, and static pressure. Each step is captured as structured data, not free-form notes.
When a high discharge temp alert fires or refrigerant pressure drops, the context is already there. Same view as the sensor data. The office can see which technician last visited, what they found, and whether the issue was flagged before.
.webp)
Every device in the system has a clear relationship to the business entities that matter. A sensor isn't just "Device #4521." It's the discharge temp sensor on Building 3's rooftop unit, last serviced on December 19th, currently showing 185°F against a threshold of 200.
This changes how alerts get handled. "Discharge temp is climbing" becomes "the RTU we serviced last week is running outside parameters, and here's the service history."
Mobile app flows match how operations actually work. A technician completing a PM visit doesn't switch between apps. They see live equipment status, work through their checklist, log refrigerant readings and amp draws, and note any issues, all in one place.
Multi-step forms with conditional logic ensure consistency across the team. Every technician follows the same procedure, captures the same data points, and the results land in structured tables that the office can filter, export, and analyse.
When an issue occurs, the full context is immediately visible: which client, which site, which unit, recent service history, refrigerant charge trends.
For service businesses, this traceability matters. It's the difference between resolving an issue on the first visit and making repeat trips because context was missing.
The pool service example is specific, but the pattern applies elsewhere.
In each case, the value comes from the same place: making the IoT data model match the business data model, so operations work inside one system instead of stitching together several.
IoT projects struggle when they force businesses to adapt their operations to match the platform. They work better when the platform adapts to match the business.
Custom Databases remove the friction that comes from parallel systems, manual data stitching, and context that lives outside the platform. When your business structure is the structure, onboarding, diagnosis, compliance, and day-to-day operations all get simpler.
This matters more as AI-driven analytics become common. Models need context to produce actionable insights, not just raw telemetry.
Have a similar challenge? If your business has hierarchies, relationships, or reference data that don't fit the standard device-and-organization model, let's talk about how Custom Databases could work for your use case.
.png)
