リード・商談・取引先・活動履歴 ── 営業の現実は、ほとんどがSalesforceの中で動いています。けれど、その中に貯まった事実を「他のシステムへ流す」「外から正しく書き戻す」段になると、結局CSVのエクスポート／インポートと手作業に戻ってしまう ── そんな現場をよく見ます。PassworkのSalesforceコネクタは、オブジェクト・項目・条件を指定した取得やSOQLの直接実行でレコードを取り出し、作成・更新・外部キーUpsert・条件削除で書き戻します。この記事では、マニフェストに定義された操作だけを根拠に、Salesforceを起点にも終点にもできる連携の実像を紹介します。
01 Salesforceとは ── 営業の事実が集まる場所
Salesforce（Sales Cloud を中心とした CRM/SFA）は、見込み客（リード）、進行中の案件（商談）、顧客企業と担当者（取引先・取引先責任者）、商談に紐づく活動やケース ── こうした営業活動の事実を、オブジェクトという単位で一元管理するプラットフォームです。日本でも、エンタープライズから成長期のSaaS・人材・製造商社まで、営業組織を持つ多くの企業が基幹のCRMとして使っています。
Salesforceに溜まるデータの特徴は、「いま、誰に、何が、いくらで動いているか」という現在進行形の事実であることです。今月のパイプライン、失注理由、担当者ごとの活動量 ── 経営にとっても営業現場にとっても、もっとも鮮度の高い一次情報がここにあります。だからこそ、この情報を分析基盤に集めたい、外部で発生したリードを正しく入れたい、というニーズが必ず生まれます。
一方で、Salesforce はオブジェクトとリレーション、項目の権限設計、外部ID（External ID）といった独自の構造を持ち、SOQL という専用のクエリ言語でデータを取り出します。この構造を踏まえずにCSVで出し入れすると、重複レコードの量産・親子関係の崩れ・上書き事故が起きやすい ── ここが連携の難所です。
02 なぜSalesforceは「連携したい」の中心になるのか
Salesforce は営業の中心にあるからこそ、両方向の連携要求が集中します。
- 取り出したい：商談・売上の実績を BigQuery や Redshift に集めて全社で分析したい。Tableau で営業ダッシュボードを作りたい。
- 入れたい：広告・Webフォーム・展示会・スプレッドシートで集めたリードを、重複させずにSalesforceへ取り込みたい。
- 書き戻したい：DWHで算出した顧客スコアやセグメント、解約リスクを、営業が見るSalesforceの項目に返したい。
この「取り出す・入れる・書き戻す」を、毎回手作業のCSVでやると、件数が増えるほど破綻します。Salesforceの構造（オブジェクト・項目・外部ID）に沿って、決定論的に・繰り返し安全に動かす仕組みが要る ── それがPassworkのSalesforceコネクタの役割です。
この記事の前提
以降で紹介する操作は、すべて Passwork のSalesforceコネクタのマニフェストとジョブランナーのSalesforceクライアントに実装されている操作です。「できたらいいな」ではなく、実際にフロー上のノードとして組める操作だけを扱います。
03 Passworkコネクタで何ができるか ── 取得と書き戻しの全操作
PassworkのSalesforceコネクタは、データを取り出す入力操作が2つ、書き戻す出力操作が4つ。Salesforceに対するひと通りの読み書きが、フロー上のノードとして揃っています。
| 操作 | 方向 | 業務の言葉でいうと |
|---|---|---|
レコード取得read |
入力 / 取得 | オブジェクト（例：商談・リード・取引先）と取得したい項目、絞り込み条件を指定してレコードを取り出します。「今月クローズ予定の商談」「特定キャンペーン由来のリード」のように、欲しい範囲だけを条件で切り出して取得できます。 |
SOQL直接実行query |
入力 / 取得 | Salesforceのクエリ言語 SOQL を文字列でそのまま実行します。親子のリレーションをまたいだ取得や、集計・複雑な条件など、項目指定だけでは表しきれない取り出しを、書き慣れたSOQLで実現できます。 |
レコード作成create |
出力 / 書込 | 入力データを項目マッピングして、新規レコードとして作成します。外部で発生したリードや案件を、Salesforceのオブジェクトに新しく登録する操作です。 |
レコード更新update |
出力 / 書込 | キー項目（既定はレコードId）で既存レコードを特定し、項目の値を更新します。「このIdの商談のフェーズと金額を書き換える」といった、対象が確定している更新に使います。 |
レコードUpsertupsert |
出力 / 書込 | 外部キー項目（External ID）を照合キーにして、該当があれば更新・無ければ作成します。外部システムのIDをキーに突き合わせるので、同じデータを繰り返し流しても重複が増えません。連携の主役になる操作です。 |
レコード削除delete |
出力 / 書込 | 指定した条件に一致するレコードを削除します。テスト投入データの後始末や、無効化が確定したレコードの整理など、条件で対象を絞った削除に使います。 |
ポイントは、取得（read / SOQL）と書き戻し（create / update / upsert / delete）が同じコネクタに揃っていることです。Salesforceから取り出して他システムへ渡すフローも、他システムからSalesforceへ書き込むフローも、どちらも同じ部品で組めます。
Upsert が連携で効く理由
外部のデータ連携でいちばん怖いのは「同じリードや顧客が二重・三重に増えていく」ことです。upsert は External ID を照合キーに、同じキーなら上書き・無ければ新規という挙動なので、毎晩同じバッチを流しても件数が膨らまない。冪等（何度実行しても結果が同じ）に近い連携を、Salesforceの標準的な外部ID機構の上で組めるのが強みです。
04 ユースケース① 商談・売上をBigQuery／Tableauへ集約する
1つめは、Salesforceを起点（取得側）にする使い方です。営業の実績を、全社の分析基盤に集めるパターン。Salesforce × BigQuery × Tableau の掛け算です。
Salesforceから商談を取得する
レコード取得で商談オブジェクトを、またはSOQL直接実行で「商談 ＋ 紐づく取引先・商談商品」をリレーションごと取り出します。前回取得以降に更新されたものだけ、といった条件で差分取得にすれば、毎日の積み増しも軽量です。
BigQuery（DWH）へ流し込む
取得した商談データを、BigQueryのテーブルへ出力します。SFA単体では見えにくい、広告費・POS売上・会計データと突き合わせられる土台が、DWH上に揃っていきます。
Tableauで営業ダッシュボードに育てる
DWHに集約したデータを Tableau で可視化。パイプライン、受注率、失注理由の分布が、リアルタイムに近い鮮度で全社に共有されます。
Salesforceの標準レポートでも基本的な可視化はできますが、「Salesforce以外のデータと並べて見たい」瞬間に、必ずDWHへの集約が必要になります。商談の事実をBigQueryに落とし、Tableauで全社の経営指標と並べる ── ここまでをひとつのフローで回せます。Tableauからさらに踏み込んだ「動くBI」の発想は、Tableauの操作から、そのままアクションを起動するでも掘り下げています。
05 ユースケース② 広告・フォームのリードを外部キーUpsertで投入する
2つめは、Salesforceを終点（書き込み側）にする使い方です。外部で発生したリードを、重複させずにSalesforceへ取り込む ── ここでUpsertが主役になります。
広告のリードフォーム、Webの問い合わせフォーム、展示会で集めた名刺リスト、営業がメンテするスプレッドシート ── 見込み客は、Salesforceの外でも次々に生まれます。これらを手作業のCSVインポートで入れると、メールアドレスは同じなのに別レコードとして増殖し、「同じ会社の同じ人が3件いる」という、営業がもっとも嫌う状態を招きます。
| 観点 | 手作業のCSVインポート | PassworkのUpsert連携 |
|---|---|---|
| 重複の扱い | 同一人物が別レコードで増殖 | External IDで突合し、あれば更新 |
| 実行頻度 | 人が思い出した時だけ | 毎晩・毎時でも自動でトリガー |
| 取りこぼし | ファイル受け渡し漏れで欠落 | 入力ソースから直接、同条件で投入 |
| 属人化 | マッピング手順が担当者の頭の中 | マッピング定義がフローに残る |
Passworkなら、入力ソース（広告・フォーム・スプレッドシート等のコネクタ）からリードを取り込み、メールアドレスや外部システムのIDをExternal ID（外部キー）に指定してUpsertでリードや取引先責任者へ投入します。同じバッチを毎晩流しても、既存は更新・新規だけ追加されるので、件数が膨らみません。新規リードの作成だけを確実にやりたい場面ではレコード作成を、対象が確定している既存案件の書き換えにはレコード更新を使い分けます。
アグリゲーターとしての価値
これは単なる「フォーム→Salesforce」の一本道ではありません。広告・フォーム・スプレッドシート・取引先がFTPへ置く受注CSV ── バラバラの入口から来るリードを、ひとつのSalesforceの規格に揃えて束ねるところに価値があります。媒体や入口が増えても、Salesforce側のUpsert定義は同じ。入口を足すたびに連携を作り直さずに済むのが、複数サービスをまたぐ連携基盤の効きどころです。
06 ユースケース③ スコアやセグメントを書き戻し、現場に返す
3つめは、取得と書き戻しをひとつの流れにつなぐ使い方です。DWHやBIで磨いた示唆を、営業が日々見るSalesforceの画面に返す ── いわゆるリバースETLの考え方です。
たとえば、BigQuery上で「直近の購買頻度・取引額・問い合わせ履歴」から顧客スコアや解約リスクを算出したとします。それがDWHのテーブルに眠っているだけでは、営業は気づけません。Passworkでそのスコアを取得し、Salesforceの取引先や取引先責任者のカスタム項目へレコード更新またはUpsertで書き戻せば、営業がいつも開く画面の中に、優先度のヒントが現れる状態になります。
分析の結果を、営業がいつも見る画面に返す。
DWHで算出したスコア・セグメントを、Salesforceの項目へ書き戻し。ダッシュボードを開かなくても、現場の判断にデータが効くようにします。
同じ発想で、セグメントを軸に顧客接点まで自動化する流れもあります。Salesforceから条件で抽出した対象を、LINEやメールの配信へつなぐパターンは、DWHのセグメントをそのままLINE・メール配信へ流すリバースETLで具体的に紹介しています。「誰に効くか」をデータで切り出す観点は、顧客セグメント別に見る統合分析も合わせて読むと、取得から活用までの流れがつかめます。
取得（read / SOQL）で持ってきて、加工し、書き戻し（update / upsert）で返す ── この一周を、人を介さずにスケジュール実行で回せること。それが、Salesforceを「入れるだけ・見るだけ」の箱から、データが循環する基盤に変える鍵です。
07 まとめ：Salesforceを「閉じた箱」にしない
Salesforceには、営業のもっとも鮮度の高い事実が集まります。しかしその価値は、取り出して他のデータと並べたとき、そして外の世界で生まれた事実を正しく書き戻せたときに、はじめて全社のものになります。
PassworkのSalesforceコネクタは、その両方向を実装事実として備えています。
- 取り出す：オブジェクト・項目・条件指定の取得と、SOQLの直接実行
- 書き込む：レコードの作成・更新
- 重複なく束ねる：外部キーによるUpsert
- 整理する：条件を指定した削除
商談をBigQuery・Tableauへ集約し、広告やフォームのリードを重複なくUpsertで投入し、DWHのスコアを営業の画面へ書き戻す ── これらは別々の機能ではなく、同じコネクタの取得と書き戻しを組み合わせただけです。Salesforceを閉じた箱にせず、データが入って・出て・また戻る循環の中心に置く。その配管を、決定論的に・繰り返し安全に組めることが、Passwork連携の利点です。
こうしたSalesforce連携は、実際の導入現場でも成果を上げています。kintoneからSalesforceへ移行する過程で会計データの整形をノーコードで解決した株式会社プレステージプランニング様の導入事例や、Salesforceパートナー自身がPassworkのETLで提案領域を広げた株式会社atsumel様の導入事例もあわせてご覧ください。
