A field operations platform, built around the home.
Silver Solutions helps families manage the home-related needs of an ageing parent, in more than fourteen states. Its crews work inside residences, often with their hands full and no signal, and the photographs and video they capture are part of what the company promises the family. Creator Scripts built the operational system of record for that work on Zoho Creator, and has engineered it continuously since 2023.
Why this domain rules out an off-the-shelf answer
Four characteristics of the work itself drove the architecture. Each one is a reason the build is custom rather than configured.
The core objects exist in no standard schema
A home, the rooms within it, the items in each room, where each item ends up, and the photographic and video record of each. No CRM, project or field-service product ships with that model.
The evidence is the deliverable
Documentation of a job is not incidental metadata. Media is a first-class object with its own lifecycle, storage, permissioning and retention, not a file attachment.
Capture happens in other people’s homes
Unpredictable connectivity, mixed devices, hands full. The capture surface has to tolerate a complete loss of network without losing work.
One process crosses independent systems
Commercial records, delivery projects, signed agreements, stored media and an external ledger, each with its own identifiers and failure modes. Orchestration has to be explicit, idempotent and recoverable.
The engineering problem, stated as constraints
Eight technical conditions the application had to satisfy. They defined the architecture.
- 1
No off-the-shelf schema fits the domain
Home, rooms, items, item disposition and the media evidencing each are the primary entities, modelled from first principles with relationships strong enough to answer questions at item granularity across thousands of jobs.
- 2
Capture must survive loss of connectivity
A surface that writes synchronously to the server fails in exactly the conditions where it is needed most. A full capture session has to complete offline and reconcile later, without duplicate or lost records on sync.
- 3
Media is a first-class object at volume
Photographs and video accumulate at a scale that cannot be held as record attachments. They need automated routing into a document store, deterministic folders per job, programmatic permissions and compression.
- 4
Orchestration spans independent authorities
A CRM, a project system, a signature service, a document store and an external ledger can each fail, rate-limit or reject on their own. Cross-system steps are explicit, idempotent operations that retry safely and surface their own failures.
- 5
Two numbering authorities must not collide
Documents are numbered inside the application and the accounting platform keeps its own sequence. Allocation detects collision, steps over consumed numbers within a bounded retry, and records a readable failure if it cannot resolve.
- 6
A priced document becomes a binding artifact
Once signed, it is a contract. Recalculation is idempotent and freezes at signature. Signature requests are single-instance: a resend recalls any outstanding request before issuing a new one.
- 7
The platform imposes an execution budget
Zoho Creator bounds the statements a single execution may run. Nightly reconciliation over a production record set is windowed by time, hard-capped by count, guarded against empty sets and instrumented to alert near its ceiling.
- 8
One record set, three device contexts
The same records on a phone in a home, a tablet on site and a desktop in the office. Not three applications: one record set, three purpose-built layout sets, one shared logic layer beneath them.
What was built and placed into production
A single Zoho Creator application as the operational system of record, with the following build scope.
- Domain data modelRelational model over homes, rooms, items, media, assessments, vendors, crews, projects and audit tables, with item-level granularity and media as a related object.Phase 1
- Offline capture surfacesSeparate offline item, photograph and video forms with local persistence and deferred sync into the main record set.Phase 1
- Media pipelineAutomated WorkDrive upload, per-job folder provisioning, programmatic share-permission management and scheduled image compression.Phase 1
- Multi-device layout setsDistinct web, tablet and phone layout sets generated over the same record set, with a shared logic layer.Phase 1 to 2
- CRM integration layerLive CRM data sources inside the application, record creation from all intake channels, mirrored state with scheduled reconciliation, duplicate suppression.Phase 2
- Project provisioningAutomatic project creation in Zoho Projects with templated task lists and milestones, owner assignment and cross-system identifier linkage.Phase 2
- Signature layerZoho Sign integration with a defined recipient matrix, reminders, expiry, recall-before-resend and status write-back.Phase 2 to 3
- Estimating engineRate cards, service lines and items, modifiers, fee buckets and baselines; idempotent recalculation; freeze at signature; change-order handling; preparer attribution.Phase 3
- Accounting integrationCustomer resolution and creation, invoice creation, document-number allocation with collision detection and bounded retry, deposit handling, error write-back.Phase 3
- Embedded analyticsIn-application HTML analytics surfaces covering operational state and data-quality exceptions, brand-styled and scoped to avoid style leakage.Phase 3 to 4
- Scheduled integrity layerWindowed, hard-capped reconciliation and cleanup jobs with exception alerting and ceiling warnings.Phase 4
- Versioned source historyA complete series of application exports, one per release, retained as the customer’s change record.Continuous
Why Zoho Creator
- It permits a bespoke relational data model, which the domain requires.
- It generates web, tablet and phone surfaces over one record set, which the mixed-device workforce requires.
- Deluge gives first-class, in-platform access to the rest of the Zoho estate and to authenticated third-party APIs, so there is no external middleware in the critical path.
- Its scheduling and workflow engines let reconciliation and integrity work live alongside the data.
Out of scope
- Replacement of the customer’s accounting ledger.
- Migration of historical records held outside the Zoho estate.
- A public customer-facing portal, deferred to a later phase.
Five layers over one record set
The application is organised as five layers. The counts describe the production build, taken from the export.
- L5
Presentation layer
37 pages, 108 reports, 35 embedded HTML analytics surfaces. Separate web, tablet and phone layouts over one record set.
- L4
Business logic layer
73 named Deluge functions across 11 namespaces, 162 form workflows, 43 record- and report-level custom actions.
- L3
Orchestration layer
20 scheduled jobs: reconciliation, media processing, document attachment, exception alerting.
- L2
Integration layer
8 configured connections, 103 authenticated API calls, 2 live CRM data sources surfaced natively in the application.
- L1
Data layer
61 forms modelling homes, rooms, items, media, assessments, estimating configuration, vendors, projects and audit trails.
Business logic lives in the 11 namespaces (estimating, CRM interaction, signature, document storage, record maintenance, deletion, notification and access control among them). Form workflows call into them rather than carrying logic inline, so the same operation behaves identically whether a field user on a phone, an office user on a desktop, a custom action, a page or a scheduled job triggers it.
- 61FormsDomain entities, estimating configuration, integration state and audit tables
- 108ReportsDefault, list, custom, calendar and kanban views across three device layout sets
- 37PagesOperational surfaces, document review and print pages, role-specific landing pages
- 162Form workflowsOn-load, on-validate, on-add and on-edit Deluge automations
- 73Named Deluge functionsOrganised into 11 namespaces by responsibility
- 43Custom actionsRecord- and report-level, for field and back-office contexts
- 20Scheduled jobsReconciliation, media processing, document attachment and alerting
- 103External API callsAuthenticated REST calls issued from Deluge over 8 configured connections
- 54,067Lines of application sourceDeluge and layout definition in the production export
Offline field capture and deferred sync
The part of the build most shaped by physical reality. Capture is separated from persistence, so nothing in the home waits on a network round trip.
In the home
The crew opens the dedicated offline capture forms on the device in hand.
Capture
Items, photographs and video are recorded against the room and the job.
No connectivity
Work is held on the device. No failed writes, no lost session.
On reconnect
Deferred sync reconciles the session into the main record set, without duplicate or lost records.
Post-processing
Media routes to WorkDrive: foldered per job, permissioned programmatically, compressed on a schedule.
Media is treated as a managed object rather than an attachment. Processing state is recorded, so a partially processed batch is visible and resumable rather than silently incomplete. The same shared logic layer serves the phone in the home, the tablet on site and the desktop in the office, so a change to a validation rule or a calculation propagates to every device context at once.
Six Zoho products, five external systems, no middleware
Every integration is implemented in Deluge inside Zoho Creator, through platform connections or authenticated API calls. There is no integration vendor in the critical path, no additional licence and no separate system to monitor. The integration logic lives with, and is versioned with, the rest of the application.
Zoho platform
- Zoho CRMLeads, deals, contacts. Two live data sources surfaced natively.Mirrored
- Zoho ProjectsDelivery projects and tasks, provisioned from a qualifying record.Provisioned
- Zoho SignAgreements and signature state, single-instance requests.Bi-directional
- Zoho WorkDriveJob media and folder tree, permissions applied programmatically.Pipeline
- Zoho AnalyticsCross-product reporting.Reporting
- Zoho CliqOperational notification.Outbound
Zoho Creator
Operational system of record. Data model, business logic, orchestration, scheduling.
8 configured connections · 103 authenticated API calls · no external middleware
Third-party systems
- Accounting platformCounterparty resolution and creation, invoice creation on signature, document-number allocation with collision handling, deposits, status write-back.Bi-directional
- Referral-partner platformQualified-record push with per-attempt success and failure logging.Outbound
- Team messagingField and vendor notifications with image cards.Outbound
- Scheduling serviceBooking and cancellation ingestion, reconciled against intake records.Inbound
- SMS gatewayScheduled reminders.Outbound
- Document servicePDF rendering support.Outbound
The patterns that make a multi-system process trustworthy
Six patterns recur across the build. Collectively they are what keeps a process spanning seven systems consistent.
Idempotency by default
Operations that touch another system are written so that running them twice is harmless. Records are adopted if they already exist rather than duplicated.
Single-instance signature
A resend recalls any outstanding request before issuing a new one and aborts if the recall fails, so two live agreements for the same document cannot exist.
Bounded sweeps
Every scheduled pass is windowed and hard-capped, with a warning raised on approach to the cap, so a growing record set degrades gracefully instead of failing at the execution limit.
Self-healing normalisation
Legacy value variants are normalised in place as records are touched, so historical data converges on current standards without a migration event.
Visible failure
Integration errors are written back onto the originating record and surfaced on an analytics panel, so a failed handoff is an operational signal rather than a silent gap.
Portable query construction
Record criteria are written as pure conjunctive chains with alternatives split into separate counts, so behaviour cannot change on the boundary between how a query is authored and how the platform serialises it.
Four engineering phases, no freeze window
Built incrementally against a live production environment. Every release is exported and retained, giving a complete and auditable history of the application source.
PHASE 1 · 2023
Core model and field capture
Homes, rooms, items, media objects, vendor and crew records. Offline capture surfaces. Media pipeline into WorkDrive.
PHASE 2 · 2024 to 2025
Multi-product integration
CRM data sources and record mirroring. Automated project provisioning with templated task structures. Agreement signature. Notification channels.
PHASE 3 · 2026
Estimating, documents, accounting
Deterministic estimating engine, document generation and client signature flow, accounting-platform integration, embedded analytics surfaces.
PHASE 4 · 2026, ongoing
Hardening
Idempotency, concurrency protection, bounded reconciliation, self-healing normalisation, exception alerting.
Outcomes, measured against the objectives
Stated as capability rather than operational data: what the architecture lets the organisation do.
Field work, evidence, assessments, priced documents and delivery all resolve to one application with one model. Questions that previously required assembling several sources are answerable from a single record set at item granularity. A single operational source of truth
Model the domain natively
A relational model descending from job to room to item, with media as a first-class related object, in production across all three device contexts.
Resilient field capture
Dedicated offline capture surfaces with deferred sync in production use. A capture session completes with no network and reconciles on reconnect.
Automated cross-system handoffs
Record creation, project provisioning, signature issuance, media routing and invoice creation run as automated, idempotent operations across seven systems with no middleware layer.
Deterministic, immutable pricing
Calculation is reproducible, recalculation is idempotent and figures freeze at signature. Change orders are modelled as related documents rather than as edits. Rate cards, service definitions, modifiers and standard language are maintained data, so rules change without a release.
Integrity work within the execution budget
Twenty scheduled jobs run to a common windowed, hard-capped, empty-set-guarded shape with ceiling alerting.
State visible in-application
Thirty-five embedded analytics surfaces expose operational and data-quality state where the work happens, with no export and no separate reporting tool.
Field service where the evidence is the deliverable?
Offline-tolerant capture, media as a managed object, explicitly modelled integration state, bounded reconciliation and idempotent cross-system operations are portable to any field-service organisation whose deliverable includes documentary evidence.