Notion Synchronization and Replication

The Achilles heel of Notion at the time of writing is that permissions control is grossly inadequate for securely sharing Notion data with clients or guests. There are four ways of sharing data, but only one is secure and more challenging to establish. The video below gives an overview, and the article goes into the implementation details of multiple Notion synchronization and replication (R/S) options.

Index of Notion Synchronization Methods

  1. Local Bi-Directional Notion Synchronization
  2. Remote Inbound Replication of Notion Data
  3. Reporting Bugs From Remote Notion Templates
  4. Synchronizing Data With External Applications

Local Bi-Directional Notion Synchronization

Who Is It For?

  • You already have a system for managing your work with multiple similar clients (e.g., your niche).
  • Your clients are entirely unrelated to your work in Notion (e.g., 99% of most businesses).
  • You want your clients to have a portal for submitting or tracking your progress on their requests.

Benefits of Local Bi-Directional Notion Synchronization

  • Your client portals can be created automatically without updating existing replication scripts.
  • You can choose whether data is synchronized inbound, outbound, or bi-directionally.
  • Each client's portal is secure and does not comingle with other client data.
Local Bi-Directional Notion Synchronization

Detailed written walkthrough of every step of the replication script.


Remote Inbound Replication of Notion Data

Who Is It For?

  • You've already established an effective system for managing your work with clients, and they are also using Notion.
  • Your clients have a variation of the native template for "Projects & Tasks" or "Projects, tasks & sprints."  Technically, we can extend any task database on the client side to work with replication.
  • You will be working in your client's workspace but still want to see a central view of your tasks and deadlines from multiple clients.

Benefits

  • All data remains on the client workspace.
  • You get the advantage of central visibility and planning across clients.

Instructions Coming Soon... 

Reporting Bugs From Remote Notion Templates

Who Is It For?

  • You have a Notion project or template that you develop and provide to clients.
  • Your template has a database for bugs or feature requests.
  • You want your client's local request to get pushed to your central feature request database while noting which client they came from.

Benefits

  • You maintain one central database for all feature requests.
  • Clients can enter new requests locally and track results.
  • Changes you make to one client are tracked centrally for planning subsequent product releases..

Requirement to Implement

The paired database for platform requests needs the following properties: 

  • Last Sync (date) - When the previous Notion synchronization took place
  • Origin (text) - Identifies the remote workspace from which data came.   This value is set in the template for new records in the remote database.
  • Remote ID (text) - The ID of the row in the primary database. This is the linking ID.
  • Link (url) - Not required on the remote side but for symmetry with the primary DB
  • Out of Sync (formula) - True for any row  where updated is more recent than Last Sync
  • Send to Dev (formula) - Your filter for which records to push to the primary DB.  For example, if you are only pushing records assigned to critical people.

More details coming soon... 

Synchronizing Data With External Applications

Instructions Coming Soon... 

>