タスク管理アプリにSalesforce連携を実装する方法（Bubble編）

準備：Salesforce側の設定

Bubbleのタスク管理アプリとSalesforceを連携するには、認証設定とTaskの操作権限を先に整えます。 新規連携では外部クライアントアプリ（External Client App）を使用します。Spring ’26以降、従来の接続アプリの新規作成は既定で制限されています。既存の接続アプリは引き続き利用できます。

Salesforceの設定で外部クライアントアプリの管理画面を開き、連携用アプリを作成します。アプリ名は、たとえば「Bubble_SF_Integration」とし、管理者の連絡先を登録します。
OAuth設定を有効にし、Bubble側で表示されるリダイレクトURLをコールバックURLに登録します。開発環境と本番環境で使うURLを照合してください。
APIアクセスの`api`と、継続利用に必要な更新トークンのスコープを選びます。ユーザーにはAPI利用権限と、対象Task・項目の操作に必要な権限を付与します。
Consumer KeyとConsumer SecretをBubbleの認証設定に使用します。秘密情報を画面や公開データに保存しないでください。

新規作成と既存連携の継続利用を分けて判断します。 接続アプリの新規作成が必要な場合はSalesforceサポートへの申請が必要です。出典：Salesforceの接続アプリ作成制限、外部クライアントアプリのOAuth設定、OAuthスコープ（確認日：2026-10-03）。

準備：Bubble側の設定

BubbleエディタでAPI Connectorを開き、Salesforce用の接続設定を作成します。利用者本人のSalesforce権限で操作する構成では、Bubbleの「OAuth2 User-Agent Flow」を検討します。以下は設定値の例です。Salesforce側の許可フローや組織ポリシーと整合するか、テスト環境で認証を確認してください。

API名：Salesforce
Authentication：OAuth2 User-Agent Flow
Authorize URL：`https://login.salesforce.com/services/oauth2/authorize`
Token URL：`https://login.salesforce.com/services/oauth2/token`
Client ID / Client Secret：Salesforceで取得した値
Scope：`api refresh_token`を基本に、ユーザー情報取得などに必要な権限を追加
Redirect URL：Bubbleが表示する値をSalesforce側と一致させます。

上記は本番ログイン先の例です。SandboxやMy Domainの利用時は対象組織の認証先に合わせます。ユーザー情報を取得するエンドポイントとID項目も設定し、認可したSalesforceユーザーとBubbleユーザーを対応づけます。

認証設定の後に各APIコールを作り、Initialize callで応答のデータ型を確認します。これは認証だけを行うボタンではなく、実際のAPIリクエストを送る操作です。作成・更新コールの初期化にはテストデータを使ってください。

出典：Bubbleの認証方式、APIコールの設定と初期化（確認日：2026-10-03）。

データモデル設計

SalesforceのTaskとBubbleのTaskデータタイプを対応づけます。以下は設計例であり、導入実績を示すものではありません。

Salesforce Taskフィールド	Bubbleタスクフィールドの例
Id	SF_Id（text）
Subject	Title（text）
OwnerId	Owner（text）
Status	Status（text）
ActivityDate	Due Date（date）

BubbleのデータタブでTaskを作り、必要なフィールドを追加します。利用者のSalesforceユーザーIDは、TaskのIDとは別に管理します。`OwnerId`は担当者を識別する値であり、表示名を送らない設計にします。

期限は日付として扱い、送信時の形式とタイムゾーンによる日付のずれを確認します。`Status`に送る値は、自社組織で使える選択肢に合わせてください。項目定義はSalesforce Taskリファレンス、日付の意味はActivityの日付項目を参照してください（確認日：2026-10-03）。

レコード取得の実装

API Connectorで「Get Salesforce Tasks」を作り、GETメソッドでQueryリソースを呼び出します。URLのホストは接続先組織に合わせ、`vXX.0`は組織で利用できるAPIバージョンに置き換えます。

GET /services/data/vXX.0/query

`q`パラメータには、次のSOQLを設定します。SF_UserIdは認可した利用者に対応するSalesforceユーザーIDに置き換え、クエリ文字列をURLエンコードして送ります。

SELECT Id, Subject, OwnerId, Status, ActivityDate
FROM Task
WHERE OwnerId = '<SF_UserId>'

取得結果の一覧はrecords配列です。`results`という固定名ではありません。`done`がfalseで`nextRecordsUrl`が返った場合は、そのURLで続きの結果を取得します。

ページ表示時のWorkflowで呼ぶならUse asをActionにして、応答のrecordsをRepeating Groupへ渡します。データソースとして参照するならDataを選びます。出典：SalesforceのSOQL取得、REST APIガイド、BubbleのUse as設定（確認日：2026-10-03）。

レコード作成・更新の実装

新規タスク作成

フォーム送信ボタンのWorkflowに、Taskを作成するAPIアクションを追加します。JSONにはフォームの値を渡します。以下の山括弧内は説明用の置換箇所です。

POST /services/data/vXX.0/sobjects/Task

{
  "Subject": "<入力されたタスク名>",
  "OwnerId": "<担当者のSalesforceユーザーID>",
  "Status": "Not Started",
  "ActivityDate": "<YYYY-MM-DD形式の期限>"
}

`Not Started`は例です。自社組織の選択肢や入力規則に合わせます。送信が成功したら、応答の小文字の`id`をBubbleの`SF_Id`へ保存します。取得時のTaskフィールド`Id`とは大文字・小文字が異なります。出典：Salesforceのレコード作成（確認日：2026-10-03）。

タスク更新

編集完了ボタンのWorkflowにPATCHアクションを追加します。URL末尾には、作成時に保存した`SF_Id`を渡します。

PATCH /services/data/vXX.0/sobjects/Task/<SF_Id>

{
  "Status": "<選択されたステータス>",
  "ActivityDate": "<YYYY-MM-DD形式の期限>"
}

通常のID指定更新は、成功時に本文のない204応答を返します。JSONが空であることだけで失敗と判定しないようにし、HTTPステータスを確認して一覧を再取得します。出典：Salesforceのレコード更新、HTTPステータス（確認日：2026-10-03）。

権限設計や更新失敗時の復旧まで外注する場合は、実装費だけでなく保守範囲も比較します。依頼先の確認項目はアプリ開発会社選び方【2026年版】比較基準・費用・契約で整理しています。

トークンリフレッシュとエラーハンドリング

更新トークンを使う場合は、Salesforceのスコープとトークンポリシーを確認します。期限切れ時には更新トークンでアクセストークンを再取得できますが、失効・取り消しなどで再認可が必要になる場合もあります。

401では認証の期限や失効、403では権限とAPI使用上限を調べます。REST APIのエラーは`errorCode`や`message`を確認し、利用者向けには再ログインや管理者への連絡など、次の操作を示します。無制限の再試行は避けてください。

出典：Salesforceの更新トークンフロー、エラーレスポンス（確認日：2026-10-03）。

テスト＆デバッグ

Bubbleデバッガーで、各APIアクションの応答とWorkflowの分岐を確認します。
Salesforce側でも対象Taskを開き、取得・作成・更新した値が一致するか確認します。サーバー側処理を調べる場合は、必要なログ設定を行います。
サンプルデータを使い、期限の空欄、許可されないStatus、権限不足、認証切れを試します。

まず少数のテストレコードで確認し、利用者を切り替えた際に他人のタスクを意図せず表示・更新しないかを確かめます。初期化も実データを変更し得る点はBubble公式の注意事項を参照してください（確認日：2026-10-03）。

運用・セキュリティ考慮

レート制限：Salesforce組織のAPI使用量を監視し、画面表示のたびに大量取得する設計を避けます。
Field-Level Security：Salesforce側のオブジェクト・項目権限に加え、Bubbleへ保存するデータの閲覧範囲も確認します。
HTTPS：通信を暗号化し、Consumer Secretやトークンをページ要素・公開データへ置かないようにします。
データバックアップ：BubbleとSalesforceのデータを定期的にエクスポートする運用を決め、復元時にどちらを正とするか整理します。

秘密情報の扱いはBubbleの認証ガイド、API上限超過時の扱いはSalesforceのエラー仕様を参照してください（確認日：2026-10-03）。

まとめ

Bubbleのタスク管理アプリにSalesforce連携を実装する際は、認証、Taskの項目対応、取得、作成・更新の順に確認します。新規連携では外部クライアントアプリを前提にし、既存連携は現在の設定と権限を確かめます。

基本操作が動いた後に、要件に応じてカスタムオブジェクトやSOQLの条件追加、大量データ向けのBulk APIを検討してください。運用開始前には認証切れや権限不足も試し、更新が失敗したときに担当者が判断できる手順を整えておきます。