Salesforce×Notion 案件サマリー自動同期ガイド 2026：3連携手法比較・Make活用設計
SalesforceとNotionの連携で、案件サマリーを自動同期し、過去の提案資料を効率的に再利用する具体的な方法を解説。設計・運用から課題解決まで、実務に役立つ情報満載です。
目次 クリックで開く
SalesforceとNotionを連携すべき実務的背景
BtoB営業の実務において、Salesforceは「商談の確度・金額・活動履歴」という構造化された数値を管理するのに優れています。しかし、営業担当者が最も必要とする「過去に顧客へ刺さった具体的な提案スライド」や「失注理由の詳細な考察」といった非構造化データは、Salesforceの標準項目だけでは管理しきれず、埋没しがちです。
構造化データ（Salesforce）と非構造化ナレッジ（Notion）の分断
多くの企業では、Salesforceに数字が入り、NotionやGoogleドキュメントに提案資料が散乱するという情報の分断が起きています。この分断は、商談準備における「資料を探す時間」を増大させ、生産性を著しく低下させます。この問題を解決するのが、Salesforceの商談オブジェクトとNotionのデータベースを自動同期させるアーキテクチャです。
関連記事：【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』
なぜ「商談サマリー」をNotionで管理すると提案精度が上がるのか
Notionは自由度の高いドキュメント作成機能を持っており、Salesforceから顧客名や商談フェーズを自動で引き継いだ「商談サマリー」を自動生成できます。ここに、Notionの強力なデータベース機能を活用した「ナレッジ共有」を組み合わせることで、成約率の高い過去の提案パターンを瞬時に呼び出すことが可能になります。これは、単なる「情報の転記」ではなく、組織的な知見の再利用を目的とした設計です。
【徹底比較】Salesforce×Notion 3つの連携手法とコスト
連携方法には、コストと柔軟性のトレードオフがあります。実務で採用される主要な3つの手法を比較します。
| 比較項目 | Notion公式コネクタ | iPaaS（Make / Zapier） | AppExchange（専用ツール） |
|---|---|---|---|
| 特徴 | 標準機能で手軽に連携 | 高度なロジック・加工が可能 | Salesforce画面内での完全統合 |
| 同期タイミング | 手動更新 / 簡易プレビュー | リアルタイム（Webhook） | 準リアルタイム |
| コスト | Notionプラン内（無料枠有） | 月額 $9〜 / $19.99〜 | 月額 数万円〜 |
| API制限 | Notion API制限に準拠 | Salesforce API制限を消費 | Salesforce API制限を消費 |
各ツールの公式サイト・事例
- Notion公式コネクタ: Notion公式ヘルプ
導入事例（ナレッジの一元化により情報検索時間を大幅削減）
- Make (旧Integromat): Make公式サイト
導入事例：世界各国で50万社以上が利用。複雑なデータ加工に強み。
- Salesforce: Salesforce公式サイト
導入事例（顧客情報の一元管理による営業効率化）
自動同期アーキテクチャの設計手順（Make活用編）
ここでは、最も汎用性が高く、コストパフォーマンスに優れた「Make」を使用した、Salesforce商談情報のNotion自動同期手順を解説します。
STEP 1：Salesforceのカスタム項目定義
まず、Salesforce側で同期フラグとなる項目を作成します。商談（Opportunity）オブジェクトに「Notion同期完了」というチェックボックス項目、および「NotionページURL」というURL項目を追加します。これにより、二重作成を防止し、Salesforceから直接Notionへ飛べる導線を確保します。
STEP 2：Notionデータベースのプロパティ設計
Notion側には、Salesforceの「商談ID（18桁）」を格納するプロパティを必ず作成してください。これを「ユニークキー」として使用します。
STEP 3：Make（iPaaS）によるシナリオ構築
Make上で以下のフローを構築します。
- Salesforce Module「Watch Objects」: 商談フェーズが「提案」に更新されたことを検知。
- Notion Module「Search Objects」: 商談IDでNotion内に既存ページがあるか検索。
- Router（条件分岐）:
- ページが存在しない場合：Notion Module「Create a Page」を実行。
- ページが存在する場合：Notion Module「Update a Page」で最新情報を上書き。
- Salesforce Module「Update an Object」: 作成されたNotionページのURLをSalesforceに書き戻す。
関連記事：Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド
実務で直面する技術的制約と解決策（トラブルシューティング）
API要求制限（API Request Limits）への対策
Salesforceには組織全体での24時間あたりのAPIリクエスト数制限があります（Enterprise Editionの場合、1,000回 + ユーザ数×20回など）。
大量の商談を一括更新すると、この制限に抵触し同期が停止します。
解決策： Makeの「Polling interval」を調整し、即時実行ではなく15分間隔などのバッチ処理にすることで、API消費を抑える設計を推奨します。
「選択リスト」と「セレクト」の同期エラー回避
Salesforceの「選択リスト（Picklist）」に新しい値が追加された際、Notion側の「セレクト」プロパティにその値が存在しないとエラーになる場合があります。
解決策： Makeのプロパティマッピングにて、Notionの値を「Dynamic」ではなく、Salesforceの値をそのまま流し込む設定にします。Notion APIは存在しない選択肢を自動作成する挙動を持つため、この特性を利用します。
「双方向同期（Notionの変更をSalesforceに戻す）」は、データ整合性の維持が非常に難しいため、初期フェーズでは「Salesforce → Notion」の一方向同期に絞り、Notionはあくまでナレッジ蓄積の場と定義することをお勧めします。
ナレッジの再利用を加速させる運用フロー
ツールを繋ぐだけでは「提案の再利用」は起きません。運用ルールの徹底が必要です。
Notion AIを活用した「過去提案」の自動要約
Notionに同期された商談サマリーには、Notion AI（月額 $10 / 1ユーザ）を導入し、議事録や提案骨子を自動要約させます。これにより、他の営業担当者は過去の膨大なドキュメントを読み込むことなく、その案件の「勝ち筋」を数秒で把握できます。
成功事例のタグ付けと自動DB連携
商談が「受注（Closed Won）」になった際、特定のタグ（例：#製造業 #コスト削減）を付与することで、Notionの「全社成功事例データベース」に自動でレコメンドされる仕組みを作ります。これにより、新任担当者でも「自社が特定の業界にどうアプローチしたか」を即座に参照できるようになります。
関連記事：SaaSコストを削減。フロントオフィス＆コミュニケーションツールの「標的」と現実的剥がし方
Claude Code MCP で Salesforce → Notion 自動同期を構築する手順
Zapier・Make に加えて、近年注目されているのが Claude Code MCP（Model Context Protocol） を活用した連携手法です。開発者が自然言語でロジックを記述できるため、複雑なマッピング設定なしに Salesforce と Notion を繋ぐ自動化を実装できます。
1. Claude Code に MCP を同時接続する
Claude Code の設定ファイル（claude_desktop_config.json）に Salesforce MCP と Notion MCP の両方を追加します。Salesforce MCP は商談オブジェクトへのアクセスを提供し、Notion MCP はデータベースへの読み書き権限を付与します。接続後は Claude Code のチャット画面から両システムを同時に操作できる状態になります。
2. 自然言語でフローを記述して実装する
接続が完了したら、以下のような自然言語指示を Claude Code に渡すだけで自動化ロジックが生成されます。
「Salesforce の Opportunity が『商談中』ステージに更新されたら、Notion の案件データベースに新規ページを作成し、商談名・金額・担当者・次回アクション日を自動転記してください」
Claude Code はこの指示を解釈して API 呼び出しコード（Python または Node.js）を生成します。Webhook トリガーと組み合わせることで、Salesforce の更新を即座に Notion へ反映する双方向同期も実現できます。
3. Make / Zapier との比較
| 項目 | Claude Code MCP | Make | Zapier |
|---|---|---|---|
| 設定方法 | 自然言語で記述 | ノーコード GUI | ノーコード GUI |
| 複雑なロジック | 得意（条件分岐・変換を柔軟に） | 複雑なマッピングは苦手 | やや複雑な処理に制限あり |
| 費用感 | Claude API クレジット消費 | 月額 9〜29 USD〜 | 月額 19.99 USD〜 |
| コード資産 | 生成コードをそのまま流用可 | プラットフォーム依存 | プラットフォーム依存 |
| 向いている用途 | カスタムロジックが多い連携 | 標準的なデータ転送 | シンプルな 1 対 1 連携 |
4. Aurant RuleHub でスコープを制限してセキュアに運用する
Claude Code MCP から Salesforce に接続する場合、意図しないオブジェクトへのアクセスを防ぐことが重要です。Aurant RuleHub を導入すると、Salesforce MCP の参照スコープを「商談データのみ」などのルールで制限できます。これにより、顧客情報や契約書データへの不必要なアクセスをブロックしながら、Notion への自動同期を安全に継続できます。
セキュアな Claude Code 活用に興味がある方は お問い合わせページ からご相談ください。Salesforce・Notion 連携の要件定義から RuleHub 導入まで一貫して支援しています。
まとめ：データと知見を統合し、強い営業組織へ
SalesforceとNotionの連携は、単なる効率化ツールではありません。営業担当者が持つ「暗黙知」を、誰でも使える「形式知」へと変換するデータアーキテクチャの構築そのものです。API制限やデータ型の不一致といった技術的ハードルはありますが、本ガイドで示したステップに従えば、持続可能な自動化基盤を構築できます。
まずは、最も重要な商談オブジェクトの数項目から同期を開始し、現場のフィードバックを得ながら拡張していくスモールスタートをお勧めします。
導入前に確認すべき「技術仕様・権限」チェックリスト
SalesforceとNotionの連携を実装する際、設定ミスにより「同期されない」「エラーが多発する」といったトラブルが頻発します。構築を開始する前に、以下の項目を必ず確認してください。
実装前のセルフチェック
- SalesforceのAPIアクセス権限： 連携に使用するユーザーに「API の有効化」権限が付与されているか（Professional Editionの場合はAPIアドオンが必要な場合あり）。
- Notionのインテグレーション設定： 対象のデータベースに対して、作成したインテグレーションが「コネクト」として追加されているか。
- 数式項目の同期： Salesforceの「数式項目」は更新トリガーが引かれないケースがあるため、Make等のiPaaS側で取得タイミングを考慮しているか。
連携に活用する公式リソース一覧
各ツールの仕様は頻繁にアップデートされるため、最新の制限値や機能については必ず以下の公式サイトを確認してください。
- Salesforce API 要求の制限および割り当て（公式ヘルプ）
- Notion API Reference（開発者向けドキュメント）
- Make Help Center: Salesforce Integration（Make公式ヘルプ）
iPaaS選定におけるランニングコスト比較
中長期的な運用を見据え、APIの消費量やシナリオの複雑さに応じたコストを把握しておきましょう。
| 項目 | Make (Coreプラン) | Zapier (Starterプラン) | Workato / MuleSoft |
|---|---|---|---|
| 月額費用目安 | $10.59〜（要確認） | $19.99〜（要確認） | 個別見積（高価格帯） |
| 主な対象層 | 中小〜中堅・情シス不在でも可 | 個人〜スモールチーム | エンタープライズ・大規模 |
| 分岐ロジック | 高度な分岐が容易 | プランにより制限あり | 極めて高度な設計が可能 |
自社に最適なツール選定や、CRM・SFAを起点としたデータ基盤の全体像については、こちらの関連記事も参考にしてください。
【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』
パイロット運用から全社展開へ：段階に分けた工程で進めるロードマップ
Salesforce×Notionの連携は、技術的には1〜2週間で組めますが、組織に定着させるには段階的な展開が必要です。いきなり全社で稼働させると、現場の反発や運用ルールの形骸化を招きます。私たちが伴走するときは、おおむね以下の3フェーズで進めます。
フェーズ1：1チーム・1事業部での小さなパイロット（最初の1〜2ヶ月）
まず10〜20名規模の営業チーム1つに絞り、片方向（Salesforce→Notion）の同期だけで開始します。Notion側に「案件サマリーDB」を作り、商談ステージが「提案中」「最終調整」に上がった案件だけが自動でNotionページとして生成される構成です。
この段階のゴールは「Notionに案件ページが自動で生まれること」ではなく、「メンバーがNotionページに何を書き込むか、書き込みのレビューを誰がするか、過去ページをどう検索して再利用するか」のオペレーションを言語化することです。技術より運用のほうが圧倒的に難しいのが現実です。
フェーズ2：複数チーム展開と運用ルールの正式化（3〜6ヶ月）
パイロットで運用が回ったら、対象チームを3〜5に広げます。この段階で必ず発生する課題が以下の3つです。
- 命名規則の揺れ：チームごとに案件タグ・業界タグの粒度が違う。全社共通のタグ辞書を整備し、四半期に1回メンテナンスする運用を立ち上げる必要があります。
- 機密案件の取り扱い：M&A・大型案件など、Notionの全社共有DBに流したくない案件が出てきます。Salesforceの「機密フラグ」を見て同期対象から除外する制御を、フェーズ2で必ず実装してください。
- 編集権限の見直し：パイロット中は全員編集可で問題なくても、人数が増えると荒れます。「閲覧は全営業／編集は担当営業＋マネージャー」のような階層を、フェーズ2の最初に設計し直すこと。
フェーズ3：他部門連携と双方向化の検討（6ヶ月以降）
営業内での運用が定着してから、カスタマーサクセス・マーケティング・経営企画など他部門へ展開します。受注確定時にCS向けオンボーディングページを自動生成する、マーケ部門が業界タグでナレッジを横串検索する、といった用途が広がる段階です。
双方向同期（Notion編集→Salesforceに反映）は、ここまで運用が固まってから検討するのが安全です。Notion側の自由度を活かすほど、Salesforce側のデータ整合性が崩れるリスクが上がります。私たちは原則「双方向化は最終手段」と伝えています。
マスタ管理の戦略：Salesforceを「正」、Notionを「読みやすい鏡」にする
連携運用で最も詰まりやすいのが「どちらのデータが正しいのか分からなくなる」現象です。これを避けるためのシンプルな原則を、最初に文書化して全員で握ってください。
| データ種別 | 真実の所在（Master） | 同期方向 |
|---|---|---|
| 商談・受注の構造化データ（金額・ステージ・確度） | Salesforce | Salesforce → Notion（片方向） |
| 提案書・議事録・参考資料 | Notion | Notionで完結（Salesforce側には参照URLのみ） |
| 担当者・組織 | Salesforce（人事マスタと連動） | Salesforce → Notion（片方向） |
| 業界タグ・提案類型タグ | Notion（マスタDBで集中管理） | Notion内で完結 |
| 失注理由・所感・案件メモ | Notion | Notionで完結（必要時に手動でSF側にコピー） |
この原則を破って「Notion側でも金額や確度を編集できる」運用にすると、半年後に必ず破綻します。Notionは『書きやすく検索しやすい鏡』、Salesforceは『数値の正本』という役割分担を、ツール設定レベルで強制しておくのが現実的です。
Make シナリオのエラー監視と自動復旧設計
同期フローを本番稼働させると、SalesforceのAPIメンテナンスやNotionの一時障害による実行失敗が月に数回は発生します。失敗したまま放置すると、Notion側に古いデータが残り続ける「サイレントな不整合」になります。Make には障害時の挙動を制御する「エラーハンドラー」機能があり、これを設定していないシナリオは本番運用に耐えません。
Break ハンドラーで未完了実行を保留する
最も実用的な設定が Break ハンドラーです。エラーが発生したモジュール（例：Notion Module「Create a Page」）の右にある円形ボタンをクリックし、「Add error handler」→「Break」を選択します。あわせてシナリオ設定の「Allow storing of incomplete executions」をオンにしておく必要があります。
Break を設定すると、失敗した実行は「Incomplete executions」に蓄積され、Make のダッシュボードから手動、または自動で再実行できます。自動再実行は最大5回まで設定可能で、再試行間隔を1回目5分・2回目15分・3回目30分のように段階的に広げることで、Notion の一時的なレート制限（通常3〜5分で解除）を回避できます。
Slack 通知で失敗を即座に検知する
Incomplete executions に溜まっていても、誰かが気づかなければ意味がありません。Break ハンドラーのルートに Slack Module「Create a Message」を追加し、失敗時に担当チャンネルへ通知する構成が実運用のベストプラクティスです。
通知メッセージには以下の変数を埋め込むと原因調査がすぐ始められます。
{{1.id}}（SalesforceのOpportunity ID）：どの商談で失敗したかを特定{{error.message}}：エラーメッセージ本文{{error.code}}：HTTPステータスコード（429はNotionのレート制限、401はトークン期限切れ）
商談データが欠損していた場合のフォールバックとしては、「商談名が空の場合はOpportunity IDをタイトルとしてNotionページを作成し、Slackに『商談名未入力』と通知する」ルーター分岐を作るのが現実的です。空の商談名でNotionにページが生まれないまま終わるより、不完全でもページを作り、担当者が気づける状態にしておくほうがデータの連続性を保てます。
エラーハンドラーモジュールを追加してもオペレーション消費は増えません。Breakルートに追加したSlack通知モジュールは失敗時のみ実行されるため、通常稼働時のオペレーション数に影響しない設計です。
Notion Workers で Salesforce データを定期同期する（2026年5月〜）
2026年5月にNotionが発表した Developer Platform（Notion Workers）は、Make のようなサードパーティ iPaaS を経由しない新しい同期の選択肢です。TypeScript で書いたコードを Notion のサーバー上でホスティングし、15分〜1日単位の定期実行または Webhook トリガーで外部データを Notion DB に書き込めます。
Salesforce との連携コスト例
公式に公開されているコスト例では、Salesforce の商談データを定期ポーリングする Workers の実行コストは 約 0.86ドル/月（15分間隔の場合）です。Make の Core プランが月額 $10.59〜であることを考えると、連携がシンプルなケースでは Workers の方がコストを抑えられます。ただし Notion Workers は 2026年8月11日までは無料のベータ期間中で、以降は Notion クレジットによる従量課金に移行します。
Make との役割分担
Notion Workers は「Notion が起点・終点になる同期」に向いており、複雑な条件分岐や複数 SaaS をまたぐ加工処理は Make の方が設定しやすい状況です。現時点では両者を使い分ける判断基準として以下が参考になります。
| 判断軸 | Notion Workers を選ぶ場合 | Make を選ぶ場合 |
|---|---|---|
| 同期の複雑さ | Salesforce → Notion の単純なデータ取込 | 複数システム経由・条件分岐・データ加工あり |
| 保守担当者 | TypeScript/JS が書ける人材がいる | ノーコードで管理者が保守したい |
| コスト優先度 | ランニングコストを最小化したい | 設定工数を最小化したい |
| エラー監視 | 自前でログ設計が必要（現時点） | Incomplete executions で GUI 管理可能 |
Notion Workers は外部エージェント API（Claude Code を Notion 内エージェントとして統合する仕組み）との組み合わせも公開されており、「Salesforce で受注確定した案件の商談ページを Claude が要約して Notion に書き込む」自動化フローが、Notion の管理コンソール内で完結する方向に進んでいます。導入計画を立てる際は、この開発動向も念頭に置いておくと将来の乗り換えコストを抑えられます。
Salesforce活用・営業DXとデータ連携のご相談
Salesforceの定着支援や営業プロセスの可視化、基幹・会計システムとのデータ連携までをまとめて支援します。現在の設定や連携方式が最適かを確認したい、という導入前後のセカンドオピニオンにも対応しています。
連携前に決めるべき 7 項目：失敗の 9 割は要件定義不足
Salesforce と Notion の連携は技術的にはそれほど難しくありませんが、運用ルールを決めずに走ると数か月でデータが汚れます。連携を始める前に、最低でも次の 7 項目は文書化してから進めてください。
- マスター（真実の所在）：商談データの正しい状態は Salesforce か Notion か。原則、構造化データは Salesforce、非構造化メモは Notion を真実とする。
- 同期方向：片方向（SF → Notion）か双方向か。双方向は競合解決が必須で運用負荷が跳ね上がる。
- 同期頻度：リアルタイム（Webhook）か数分置き（バッチ）か。営業 KPI が日次でいいなら数分バッチで十分。
- 差分同期キー：Salesforce の Id（18 桁）を Notion 側のプロパティに保存し、これで突合する。Notion の Page ID を SF の外部 ID に持たせると逆引きも可能。
- 共有粒度：Notion の DB を全社共有か、案件ごとのページを担当者にだけ共有か。共有設定は Notion 側で固定する運用が安全。
- 削除のセマンティクス：SF で商談を削除した時 Notion 側はどうするか。論理削除（アーカイブタグ）が基本。
- 機密項目の扱い：金額・受注確度などを Notion に流さないルールを決める。Notion はゲスト共有や URL 漏洩で社外露出するリスクあり。
実装パターン 4 種の比較：自社規模で正解が変わる
| パターン | 仕組み | 料金感 | 向いている規模 | 注意点 |
|---|---|---|---|---|
| Make / Zapier シナリオ | SaaS 間の Webhook をノーコードで仲介 | 月数千〜数万円 | 営業 10 名以下 | シナリオ数が増えると保守不能、エラー再実行が手作業 |
| Workato / Boomi 等の iPaaS | レシピをチームで共同保守、監視機能あり | 月数十万円〜 | 営業 50 名以上の中堅企業 | 導入コストとライセンスが重く、ROI 計算が必要 |
| Salesforce Flow + Notion API 直叩き | SF 側のフローから HTTP Callout で Notion API を叩く | SF ライセンス内 | SF 開発者がいる組織 | API 制限とエラーハンドリング設計が必要 |
| 独自 Lambda / Cloud Functions | SF Streaming API → Lambda → Notion API | クラウド従量料金のみ | エンジニアリング体制がある | 監視・テスト・デプロイ運用を作る覚悟が必要 |
「案件サマリー」を Notion で再利用する設計テンプレ
Salesforce の商談オブジェクトに紐づけて、Notion 側で「案件サマリー」DB を作るのが定番設計です。提案資料・議事録・参考資料を Notion 側に集約することで、商談を進めるうちに自然と組織のナレッジが溜まる仕組みになります。
Notion DB のプロパティ設計テンプレ（最小限）：
- Name（タイトル）：案件名（SF と同期）
- SF Opportunity ID（テキスト、ユニーク）：突合キー
- Stage（セレクト）：Salesforce のステージ名（同期）
- Owner（人）：担当者
- Industry（セレクト）：業界タグ（再利用検索キー）
- Pain points（マルチセレクト）：課題タグ
- Solution archetype（セレクト）：提案類型タグ
- Last sync（日付）：最終同期日時
- Sensitivity（セレクト）：「全社共有」「営業のみ」「経営のみ」
本文（Notion ページ内）には、提案サマリ・議事録・添付資料リンクを書きます。Industry / Pain points / Solution archetype のタグを揃えておくことで、似た案件の過去ページを Notion 検索で一気に引っ張れるようになります。これが「提案の再利用が劇的に加速する」核心です。
運用 90 日で計測する KPI 例
- 提案資料の作成時間（同期前後）：類似案件の Notion ページから流用したことで何時間短縮できたか。
- SF 入力率：同期で Notion に良い情報が出ることを動機に、SF 側の入力品質が上がるか。
- 商談 → 契約のリードタイム：ナレッジ再利用が初回提案のスピードに効くか。
- 勝率（Win Rate）：同じ業界・同じ Pain points セグメントでの勝率比較。
- 同期エラー率：iPaaS / Flow の失敗ジョブ数。週次で監視。
セキュリティ・ガバナンス チェックリスト
- Notion の DB に対してゲスト共有が無効化されているか（管理コンソール）。
- SF 側で項目レベル セキュリティ（FLS）が設定されており、API ユーザーが金額・受注確度を読めるか必要に応じてマスクしているか。
- 同期ジョブのサービスアカウントが社員退職時に切り替えられる設計か。
- Notion の Audit Log（Enterprise 限定）でページ閲覧・編集履歴が監査できる体制か。
- 個人情報を含むメモを Notion に貼らないルールが運用上のチェックに入っているか。
FAQ
- Salesforce の Account / Contact も Notion に同期した方がいい？
- 結論はノーです。Salesforce が真実のオブジェクトを Notion でも編集してしまうとデータ不整合が必ず起きます。同期するのは「Notion 側でメモを書きたい」対象のみに絞るのが鉄則です。
- Notion AI と組み合わせるとどうなる？
- Notion AI に同期した商談ページを読み込ませると「過去 1 年で似た失注理由のあった案件は？」「業界別の勝ち筋メッセージを要約して」といった分析が一発で出ます。Salesforce 単体ではできない非構造化情報の AI 解析が、Notion 連携の最大のリターンです。
- 双方向同期は本当に避けた方がいい？
- 避けられるなら避けてください。SF と Notion の更新タイムスタンプ競合解決を作り込む工数より、Notion 側を見つつ SF を編集する運用の方が安く堅牢です。
- Salesforce のカスタムオブジェクトと Notion を連携できますか？
- API 上は可能です。ただし Salesforce 側でカスタムオブジェクトの API 名と Notion 側のプロパティ名のマッピング表を別途管理する必要があり、保守コストが標準オブジェクトの 2〜3 倍になります。
- 連携停止後、Notion 側のデータは消えますか？
- 消えません。Notion DB は独立して残ります。ただし Stage や Owner が古いまま固定されるので、定期的に「Last sync が N 日以上前」のページを棚卸しする運用が必要です。
関連記事
CRM・営業支援
Salesforce・HubSpot・kintoneの選定から導入・カスタマイズ・定着まで一貫対応。営業生産性を高め、商談化率を改善します。
