How to Mirror Your CRM Location Tree in Cloud Storage

• [ ] A CRM that fires a create/update trigger with the record's location fields.
• [ ] Cloud-storage API access on a shared library (not a personal drive; it must survive staffing changes).
• [ ] An automation runner (n8n, Make, a background worker) to receive the trigger and call the storage API.
• [ ] The CRM's location taxonomy (parent community, location, unit) and the record's reference code.

1. 1

   Mirror location tree

   Mirror the CRM's location-tree order, top-down. Build the path in the same order the CRM organises it (parent community, then location, then the unit) rather than an inverted or ad-hoc order. The folder tree should read like the CRM:

2. 2

   Name leaf folder

   Name the leaf folder so it's unique and recognisable. Name the unit folder with both its number and its reference code (for example Unit 603 - REF-7506) so it's unambiguous even when numbers repeat across locations.

3. 3

   Route typed subfolders

   Route contents into typed subfolders. Inside the record folder, separate contents by type: an owner subfolder named for the owner (falling back to a generic Owner label when no name exists), and dedicated Photos and Videos subfolders that uploads are routed into by file type. Store external links (a video URL, a virtual-tour URL) as individual .txt files inside a Links folder, and skip that folder entirely when there are no links.

4. 4

   Make idempotent

   Make provisioning idempotent. A create/update trigger can fire more than once. Check-or-create each folder so repeat triggers don't produce duplicates, and normalise names (trim, case, separators) so Midtown and midtown don't become two folders.

5. 5

   Sync vs create once

   Decide per artifact: sync-always vs create-once. Re-sync documents and links on every record update so the folder stays current, but keep genuinely one-time artifacts (a generated QR code, for instance) generated only once. Don't redo settled work on every edit.

6. 6

   Handle duplicates

   Handle duplicated records. When a record is duplicated in the CRM, auto-provision a fresh folder for the copy, upload its media anew, and carry documents and links over per the CRM. A duplicate should never share or overwrite the original's folder.

7. 7

   Add error handling

   Add error handling and self-healing to every node. Give each step a fallback so a transient API failure doesn't leave a half-provisioned folder, and regenerate missing derived artifacts on the next run rather than failing outright.

   Properties / {Parent Community} / {Location} / Unit {Number} - {Reference}

• A new record produces the folder path Parent / Location / Unit {No} - {Ref} with Owner {name}, Photos, Videos, and (when links exist) Links subfolders.
• Firing the trigger twice creates no duplicate folders.
• Updating the record re-syncs documents and links, while the QR code is unchanged.
• Duplicating a record provisions its own separate folder.
• The upload path works from a desktop browser, not only via a mobile QR scan.

• [ ] Storage root is a shared library with org-level consent.
• [ ] Path mirrors the CRM location tree; leaf named Unit {No} - {Ref}.
• [ ] Typed subfolders (Owner / Photos / Videos / Links) route by content type.
• [ ] Provisioning is idempotent and name-normalised.
• [ ] Documents/links re-sync on update; one-time artifacts stay one-time.
• [ ] Duplicated records get their own folder.
• [ ] Every node has error handling and self-healing.
• [ ] Upload verified from desktop and mobile.

• Mirroring the system-of-record's taxonomy is the core idea; it makes the folders navigable without the CRM open. Keep the automation in step with any change to the CRM's location tree.
• A natural follow-on is on-request media upload (a per-record QR that lets field staff drop photos straight into the right subfolder from a phone), which builds on this provisioning foundation.