Turning a spreadsheet into the front end of a data warehouse

Every appraisal rests on comparable properties: recent sales, leases, and expense records that justify a valuation. That data is the firm's real asset. It arrives from external providers in inconsistent formats, accumulates over years, and has to be searchable, editable, and defensible.

Warehouses are good at holding it. Appraisers are not warehouse users. They work in spreadsheets, and any system that made them leave one to query comps would go unused, the same constraint that shaped the platform, applied one layer down.

The spreadsheet had to become a legitimate interface to a warehouse, without the appraiser ever knowing that is what they were using.

Warehouse access through the platform, not from the add-on. Every data operation goes through the core platform. The add-on renders the interface and keeps the sheet in step with the schema; the platform owns credentials, query cost, tenancy boundaries, and the authority to say what a valid record is. The rule is deliberate: a constrained, hard-to-update client should never hold anything security-sensitive or business-critical. Both add-ons follow it, by design rather than by accident.

The schema is data, not code. The appraisal data schema lives in a centrally-hosted spreadsheet, loaded and cached at runtime. It is not compiled into either add-on.

That single decision pays repeatedly. The schema can be extended without a release, in a tool the domain experts already use. One schema drives different field subsets per record type, so records that overlap share definitions and diverge only where they genuinely differ. And because the same definition flows through to the report, a field is described once rather than three times in three places that can drift apart.

Importing data that was never meant to fit. Comp data arrives as whatever the source provides. The import subsystem maps arbitrary incoming columns onto the schema, flags unmapped and invalid columns visually in the sheet, and walks the user through reconciling free-text values against the permitted options.

Two constraints shaped it. Rows are copied in bounded chunks so a large import cannot hit the execution ceiling mid-write. And because the reconciliation flow spans several dialogs, and Apps Script keeps no memory between them, the work in progress is persisted as a queue that survives each interaction. The user sees a conversation; the runtime sees a series of unrelated invocations.

Maps: defined here, drawn there. Location maps are a good illustration of the seam between the two add-ons. Tables does not generate map images. It captures the appraiser's selection of markers, addresses, and map style, validates it, and writes it into the sheet as a structured, named block. Writer picks that block up at merge time and renders the actual image into the report.

Neither add-on calls the other. The spreadsheet is the contract, which means either can be deployed, debugged, or rewritten without touching the other.