Notion ERP with Make
Make is a no-code automation platform. The four Make scenarios below run every flow of this doc with a Notion database playing the ERP (Mock Counterparties:Counterparty Name, SIRET Number, Industry, Address, City, ID tomorro). Use them as a head start if you run Make, or as a reference implementation for n8n, custom code or another ERP: only the ERP modules change.
Notes
Notes
- Connections: the Tomorro calls use an API Key Auth keychain (header
x-api-key), the Notion calls a Notion connection invited on the counterparty database. - Notion calls go through Make an API Call (Notion API version
2022-06-28), so the raw Notion JSON is parsed in code modules. With your ERP, replace these modules with its own connector. - Webhooks: Flows 1 and 2 start from a Notion webhook (Watch Events, event Page: Properties updated), within a minute or two of the change: Notion groups its events before sending them. No polling. The webhook receives events from the whole Notion workspace: pages the connection cannot read are skipped by an Ignore error handler, and a filter keeps only the counterparty database.
- Retries: the Tomorro calls that write (create, update) retry automatically, 3 times, 1 minute apart. A bundle that still fails is kept as an incomplete execution, to review in Make.
- Sync state: Flow 3 saves the last
updatedAtit processed in a Make data store, and only reads what changed since. - Pages: Flow 0 reads up to 100 counterparties per run and can simply be re-run. Flow 3 reads the 50 latest updates per run; paginate with
pagination.next_cursorabove that. - Industry: labels are matched case-insensitively on the Tomorro options. A Notion value missing from Tomorro is left out and reported in the
warningoutput of the code module.
About the code below
The scenarios are mostly standard modules. The logic lives in a few short JavaScript snippets, run by Make Code modules: read the ERP row, translate the Industry label into its option id, and compare both sides before writing. They are already inside the blueprints: you only need to copy them if you build the flows yourself.FIELDS with yours (see 1.3).
Flow 0 - [Notion → Tomorro → Notion] Initialisation
Make scenario Flow 0 - Initialisation, scheduling on demand (Run once).Step 0 - List the counterparties not linked to Tomorro
ID tomorro, then iterate over body.results:Step 1 - Get the Industry option ids
Step 2.1 - Build the counterparty body
id and properties, and data of step 1. Skips rows already linked or without a name, and translates the Industry label into its option id.Step 2.2 - Create the counterparty in Tomorro
skip not true, with a Retry error handler.Step 3 - Write ID tomorro back to Notion
Flow 1 - [Notion → Tomorro → Notion] Counterparty created in the ERP
Make scenario Flow 1 - Creation, triggered by a Notion webhook.Step 0 - Notion webhook: a counterparty row is edited
GET /v1/pages/{entity.id}, filtered on the counterparty database.A row added in Notion is often empty when it is created: the counterparty is ready once its fields are filled. So Flow 1 listens to property updates, and only creates a counterparty for a row with a name and no ID tomorro.Step 1 - Get the Industry option ids
Step 2.1 - Build the counterparty body
body.id and body.properties of module 2.Step 2.2 - Create the counterparty in Tomorro
skip not true, with a Retry error handler.Step 3 - Write ID tomorro back to Notion
Flow 2 - [Notion → Tomorro] Counterparty updated in the ERP
Make scenario Flow 2 - Update from ERP, triggered by a Notion webhook.Step 0 - Notion webhook: a counterparty row is edited, read it
GET /v1/pages/{entity.id} filtered on the counterparty database, then read the values. Rows without ID tomorro are left to Flow 1.Step 1.1 - Read the current counterparty
skip not true (row linked to Tomorro and named).Step 1.2 - Get the Industry option ids
Step 2.1 - Compare Notion and Tomorro
data of steps 1.1 and 1.2. Builds a PATCH body with the differences only. A Tomorro Industry that is not a valid option id counts as empty, so it is repaired.Step 2.2 - Update the counterparty in Tomorro
changed = true, with a Retry error handler.Flow 3 - [Tomorro → Notion] Counterparty updated in Tomorro
Make scenario Flow 3 - Update from Tomorro, every day at 8:00.Step 0 - Get the last updatedAt processed
flow3_last_updated_at. Empty on the first run.Step 1.1 - List the counterparties, latest updates first
Step 1.2 - Keep the counterparties updated since the last run
data and pagination.has_next of step 1.1.Step 1.3 - Remember the latest updatedAt
flow3_last_updated_at, value newLastUpdatedAt of step 1.2.Step 1.4 - Get the Industry option ids
Step 2.1 - Find the ERP counterparty
ID tomorro is the counterparty id:Step 2.2 - Compare Tomorro and Notion
name and fields, the options of step 1.4. Skips a Tomorro counterparty when no ERP row has its id, translates the Industry option id back to its label, and builds the Notion properties that differ.Step 2.3 - Update the counterparty in Notion
changed = true.Make blueprints
A blueprint is a Make scenario exported as JSON. Import it and every module comes back configured, code included.Get the 4 Make blueprints
Import
Connect
- Tomorro HTTP modules: create an API Key Auth keychain: key name
x-api-key, value your API key, placed in the header. - Notion modules: select a Notion connection that has access to your counterparty database.
- Flows 1 and 2: on the Watch Events trigger, create a webhook with the event Page: Properties updated, one per scenario.
- Flow 3: on both Data store modules, create a data store with a
keyand a textvalue.
Replace the ids
YOUR_NOTION_DATABASE_ID and YOUR_NOTION_DATA_SOURCE_ID with your database (Notion API calls and the webhook filters), and the smart field ids (URLs and FIELDS in the Code modules) with yours.Run