This document outlines the system architecture, technical decisions, and maintenance procedures for the Drawboard Master ↔ Restricted Database Sync system.

Project Context

Key Requirements:

• Master database visible only to Alistair
• Each restricted user gets their own separate database
• Restricted users see only their own records (filtered by "Person Responsible" or similar property)
• Changes in Restricted databases sync to Master
• Optionally: Changes in Master sync down to relevant Restricted databases (bi-directional)
• Some properties sync (e.g., "Contractor Notes"), others stay local (e.g., "Internal Notes")

Client Setup:

• Alistair has created Make.com account
• Make invite sent to [email protected]
• Flexible schema during build phase; locked once live

Scaling Strategy (Dynamic Database Search)

We have moved away from hardcoded routers for each user. The system now uses a Dynamic Search strategy.

• Logic: The Make scenario reads the Person Responsible name (e.g., "Mitchell") and searches for a Notion Database named Restricted - name.
• Benefit: Zero-touch scaling. To add a new user, the client simply duplicates the Restricted Template, renames it Restricted - {Name}, and adds the name to the Person Responsible property options. No Make scenario edits are required.

Technical Decisions

• Sync architecture:
  • Using completely separate Notion databases (not views) to enforce true data isolation
  • Make.com as the bridge between Master and Restricted databases
  • Native Notion automations trigger Make webhooks (avoids polling, reduces Make operations)
• Concurrency control:
  • Enable "Sequential processing" in Make.com scenario settings.
  • Ensures each run finishes completely before the next starts (FIFO queue).
  • Critical for preventing race conditions and ensuring atomic updates, preventing rapid-fire edits from overlapping.