Skip to main content
In this example, we build the whole integration with Make as the middleware, and a Notion database playing the role of the ERP, the counterparty base. Each of the four flows is one Make scenario: you can watch it run end to end in the video, then import the same scenarios from the blueprints.

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.
The scenarios are a working example, not a ready-made integration. They make choices you may want to change:
  • 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 updatedAt it 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_cursor above that.
  • Industry: labels are matched case-insensitively on the Tomorro options. A Notion value missing from Tomorro is left out and reported in the warning output 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. In every case, replace the smart field ids in FIELDS with yours (see 1.3).

Flow 0 - [Notion → Tomorro → Notion] Initialisation

Make scenario Flow 0 - Initialisation, scheduling on demand (Run once).
1

Step 0 - List the counterparties not linked to Tomorro

Make modules 1, 3Query the database for rows with an empty ID tomorro, then iterate over body.results:
2

Step 1 - Get the Industry option ids

Make module 2
3

Step 2.1 - Build the counterparty body

Make module 4Inputs: the row 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.
4

Step 2.2 - Create the counterparty in Tomorro

Make module 5, filtered on skip not true, with a Retry error handler.
5

Step 3 - Write ID tomorro back to Notion

Make module 6

Flow 1 - [Notion → Tomorro → Notion] Counterparty created in the ERP

Make scenario Flow 1 - Creation, triggered by a Notion webhook.
1

Step 0 - Notion webhook: a counterparty row is edited

Make modules 1, 2Watch Events, event Page: Properties updated, then read the raw row with 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.
2

Step 1 - Get the Industry option ids

Make module 3Same call as Flow 0 step 1.
3

Step 2.1 - Build the counterparty body

Make module 4Same code as Flow 0 step 2.1, inputs body.id and body.properties of module 2.
4

Step 2.2 - Create the counterparty in Tomorro

Make module 5Same call as Flow 0 step 2.2, filtered on skip not true, with a Retry error handler.
5

Step 3 - Write ID tomorro back to Notion

Make module 6Same call as Flow 0 step 3.

Flow 2 - [Notion → Tomorro] Counterparty updated in the ERP

Make scenario Flow 2 - Update from ERP, triggered by a Notion webhook.
1

Step 0 - Notion webhook: a counterparty row is edited, read it

Make modules 1, 2, 3Watch Events, event Page: Properties updated, GET /v1/pages/{entity.id} filtered on the counterparty database, then read the values. Rows without ID tomorro are left to Flow 1.
2

Step 1.1 - Read the current counterparty

Make module 4, filtered on skip not true (row linked to Tomorro and named).
3

Step 1.2 - Get the Industry option ids

Make module 5Same call as Flow 0 step 1.
4

Step 2.1 - Compare Notion and Tomorro

Make module 6Inputs: the values of step 0, 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.
5

Step 2.2 - Update the counterparty in Tomorro

Make module 7, filtered on 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.
1

Step 0 - Get the last updatedAt processed

Make module 1Data store > Get a record, key flow3_last_updated_at. Empty on the first run.
2

Step 1.1 - List the counterparties, latest updates first

Make module 2
3

Step 1.2 - Keep the counterparties updated since the last run

Make module 3Inputs: the saved value of step 0, data and pagination.has_next of step 1.1.
4

Step 1.3 - Remember the latest updatedAt

Make module 4Data store > Add/replace a record, key flow3_last_updated_at, value newLastUpdatedAt of step 1.2.
5

Step 1.4 - Get the Industry option ids

Make module 5Same call as Flow 0 step 1, once per run.
6

Step 2.1 - Find the ERP counterparty

Make modules 6, 7Iterate over the counterparties of step 1.2, and look up the Notion row whose ID tomorro is the counterparty id:
7

Step 2.2 - Compare Tomorro and Notion

Make module 8Inputs: the rows of step 2.1, the counterparty 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.
8

Step 2.3 - Update the counterparty in Notion

Make module 9, filtered on 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

The Sync counterparties - Flow 0 to 3 files: Flow 0 - Initialisation, Flow 1 - Creation, Flow 2 - Update from the ERP and Flow 3 - Update from Tomorro, one JSON file each.
1

Import

In Make, create a scenario, open the ⋯ menu, choose Import blueprint and select one of the downloaded JSON files. Repeat for each flow.
2

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 key and a text value.
3

Replace the ids

Replace 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.
4

Run

Run Flow 0 once, check a few counterparties in Tomorro, then turn on Flows 1, 2 and 3.