n8nとNotionの同期では、元データのIDとNotionのページIDを対応させ、新規作成と更新を分けます。ページのタイトルだけで検索すると、同名の別件や名前を変えた既存ページを取り違える可能性があります。
Notion側にも、元データの識別項目を用意する
問い合わせ管理ならrequest_idを専用のプロパティとして持たせます。n8n側の記録へは、作成したNotionページIDも残します。元IDとページIDを行き来できることが、再送や名前変更への備えになります。
同期記録の例
source_id:sample-001
notion_page_id:作成されたページID
source_updated_at:元データの更新日時
synced_revision:同期した版
status:created / updated / needs_review
Notionの画面の名称や、APIのdatabase/data sourceの扱いは版で変わるため、使用中のノードが求めるIDを確認します。
接続へ、対象データへのアクセスを渡す
NotionのIntegrationを作るだけでは、対象ページへアクセスできるとは限りません。同期するデータの親ページや対象に接続のアクセスを与え、必要な操作ができるかを試します。ノードの対応操作は公式Notionノードで確認できます。
初回は試験用の対象へ一件だけ作成します。元の項目がNotionのプロパティの型と合うかを見て、本文ブロックへ入れる内容と検索する項目も分けてください。
照合できた一件だけを更新する
| 照合結果 | 処理 |
|---|---|
| 元IDに対応するページが0件 | 新規作成するか、未登録を確認する |
| 一件 | そのページIDだけを更新する |
| 二件以上 | 重複として止め、担当が整理する |
「見つからないから作成する」処理は同時実行で重複する場合があります。元IDの処理権を別の保存先で確保するか、同じIDが重ならない運用を組み合わせます。
双方向にする前に、どちらが正本かを決める
元システムとNotionの両方で編集できると、更新が互いに戻されることがあります。項目ごとの編集担当と、同時変更があった場合の優先を決めます。元データの削除を、Notionの永久削除へ自動で直結させないようにします。
一件の新規登録、名前変更、同じIDの再送を順に試します。ページが増えず正しい対象へ更新されたら、その記録を残して件数を増やしてください。重複と結果不明は二重実行の設計へ分担します。