営業チームのSalesforceを会計ソフトやフォームなど社外のサービスとつなぎ始めると、「API」「Apex」「接続アプリケーション」という言葉が一度に出てきます。題材は、社員30名ほどの法人向けサービス会社の営業チーム（営業5名・営業マネージャー1名）の組織で、受注後の作業を管理するカスタムオブジェクト「導入プロジェクト」を使っています。読み終わると、APIが使える契約かの確認、連携専用ユーザーの作成、外部サービスに渡す接続設定、Apexを頼むかの判断、Apexを本番に入れる条件の確認までを、プログラムを書かない管理者が一通りできます。作業はシステム管理者のユーザーで行います。APIは Enterprise・Unlimited・Performance・Developer Edition で標準、Professional Edition では有償の追加が前提になります。画面は Lightning Experience で説明し、Classic の画面の説明は読み飛ばしてかまいません。
この記事の内容
Salesforceを外とつなぐ方法の地図
外部とつなぐ手段は5つあり、下に行くほど自由度も維持の負担も増えます。
| 手段 | 例 | 管理者が自分でやれる範囲 |
|---|---|---|
| 標準の連携機能 | Slack連携、メール連携、カレンダー連携 | ほぼ全部。画面の設定だけで終わる |
| AppExchange のアプリ | 名刺管理、電子契約、帳票作成 | インストールと権限の割り当て。中身は提供元が保守する |
| iPaaS（連携ツール） | Zapier、Make、n8n などのつなぎ役 | 連携ユーザーと接続の準備、ツール側の画面での設定 |
| API を使う外部サービス | 会計ソフト、自社サイトのフォーム、基幹システム | 連携ユーザー、外部クライアントアプリケーション、権限の準備まで |
| Apex（Salesforce内のプログラム） | 複雑な自動処理、外部への独自の送信 | 要件の整理と受け入れ確認。書くのは開発者 |
順番は上から当てはめます。会計ソフトに受注を送るなら、まず相手側にSalesforce用の連携が無いかを見ます。多くは相手側に「Salesforceと接続」のボタンがあり、管理者は連携用のユーザーでログインして許可するだけです。Apexが要るのは、相手側に連携が無く、フローの外部呼び出しでも足りないときに限られます。
APIは「外部のプログラムがSalesforceのデータを読み書きする入口」で、iPaaSもAppExchangeのアプリも裏ではこれを使っています。標準の連携機能以外はほぼ全部APIの契約と権限に依存するので、最初に確かめるのは自社の組織でAPIが使えるかどうかです。
先に決めること
APIが使える契約かを確かめる
APIが使えるかはエディションで決まります。Salesforceのナレッジ記事「API アクセスのある Salesforce Edition」では次のように分かれています。
| エディション | API | 補足 |
|---|---|---|
| Enterprise・Unlimited・Performance・Developer | 使える | 標準で含まれる |
| Professional | 標準では使えない | 有償の「Web Services API」で使えるようになる。営業担当に依頼する |
| Essentials・Group | 使えない | 追加もできない。アップグレードが必要 |
| Starter・Pro Suite | 公式記事の一覧に記載なし | 契約前に営業担当に確認する |
Professional Edition で外部サービスとつなぐ予定があるなら、契約の段階で「Web Services API」を見積もりに入れます。名前の似た「追加のAPI呼び出し（Additional API Calls）」は、すでにAPIが使える組織の回数を増やす別の製品で、これだけではAPIは有効になりません。後から気づくと、連携ツールの初期設定で「API is not enabled for this Organization or Partner」というエラーが出て止まります。データ移行のためだけなら、営業担当に依頼して期間を決めて一時的に有効にしてもらう形も公式に用意されています。AppExchange のアプリには、認定を受けて Professional Edition でも動くものがあるので、提供元に確認します。
呼び出し回数の上限を見積もる
APIには、24時間あたりに組織の合計で呼べる回数の上限があります。Salesforce Developers の「API Request Limits and Allocations」の数字は次のとおりです。
| エディション | 24時間あたりの上限 |
|---|---|
| Enterprise、API を追加した Professional | 100,000 + Salesforce ライセンス数 × 1,000 + 購入した追加分 |
| Unlimited・Performance | 100,000 + Salesforce ライセンス数 × 5,000 + 購入した追加分 |
| Developer Edition | 15,000 |
Enterprise Edition で Salesforce ライセンスが7つ（営業5名・マネージャー1名・管理者1名）なら、100,000 + 7 × 1,000 で107,000回です。この式は Salesforce ライセンスだけの組織の場合で、Salesforce Platform や Lightning Platform – One App、コミュニティ系のライセンスが混ざるときは、ライセンス種別ごとに決まった回数（Salesforce Platform は1,000、One App は200など）を種別ごとに掛けて足します。
ほかに、20秒以上かかる要求の同時実行は本番組織とsandboxで25まで（Developer Edition とトライアルは5まで）という決まりもあります。24時間の上限を超えても有償契約なら一時的に処理は続きますが、固い天井があり常用はできません。インストールしたAppExchangeのアプリが呼ぶAPIも組織の回数に含まれます。
107,000回は十分に見えますが、連携ツールが「5分ごとに全商談を1件ずつ読む」設定だと、商談500件で1日14万回を超えます。連携先を足すたびに、何分おきに何件を読むかを相手側に聞いて足し算します。
連携ごとに専用のユーザーを作るか
外部サービスがログインするときのユーザーは、連携ごとに専用のものを1つ作ります。公式ヘルプでも、最小権限の原則に従って連携ごとに1ユーザーが勧められています。
担当者本人のユーザーでつなぐと、その人の退職でユーザーを無効にした日に連携が止まり、変更履歴も「営業の山田さんが夜中の3時に100件更新した」ように見えて調べにくくなります。
設計表
この組織で、会計ソフトに受注済みの商談を渡す連携を作る場合に用意するものです。
| 用意するもの | 設定値 | 理由 |
|---|---|---|
| 連携ユーザー | 名前「連携 会計ソフト」、ユーザーライセンス「Salesforce Integration」 | 画面にはログインできず、APIだけ使える |
| プロファイル | Minimum Access – API Only Integrations | 連携用ライセンスに付く最小権限のプロファイル |
| 権限セットライセンス | Salesforce API Integration | 権限セットで付けられる権限を広げる |
| 権限セット | 「連携_会計ソフト」 | 商談と取引先の参照、導入プロジェクトの参照と編集だけを付ける |
| 外部クライアントアプリケーション | 名前「会計ソフト連携」、配信状態「ローカル」 | 会計ソフトに渡す鍵の発行元 |
| OAuth 範囲 | API を使用してユーザーデータを管理 (api) | データの読み書きだけを許す |
| API 使用状況通知 | しきい値 80%、通知間隔 24 時間 | 上限に近づいたら管理者にメールが届く |
「Salesforce Integration」のユーザーライセンスは、Enterprise・Unlimited・Performance Edition の各組織に5つ、Developer Edition に1つ含まれます。Professional Edition は対象外なので、通常の Salesforce ライセンスを1つ連携用に回し、権限セットで絞ります。
作る手順
1. APIが有効かを確かめる
- 画面右上の歯車アイコンから「設定」を開きます。
- 「クイック検索」に「システムの概要」と入力します。
- 「システムの概要」を開きます。
- 「API 使用状況」の欄に、過去24時間の使用回数と上限が出ているかを見ます。
この欄が出ていればAPIは使える契約です。あわせて、APIを使うユーザーに「API の有効化」権限が付いていることも確かめます。
2. 連携ユーザーを作る
- 「設定」の「クイック検索」に「ユーザー」と入力し、「ユーザー」を開きます。
- 「新規ユーザー」をクリックします。
- 「姓」に「連携」、「名」に「会計ソフト」と入力します。
- 「メール」に、管理者が受け取れるアドレスを入力します。
- 「ユーザー名」に、メール形式で組織内で重ならない名前（例 integration-accounting@自社ドメイン）を入力します。
- 「ユーザーライセンス」で「Salesforce Integration」を選びます。選択肢に出ないときは、組織の分を使い切っています。
- 「プロファイル」で「Minimum Access – API Only Integrations」を選びます。
- 「保存」をクリックします。
「メール」は個人ではなく管理者が共有で見られるアドレスにします。このプロファイルの「API だけ使える」制限は、コピーしても外せません。このままでは商談も取引先もほぼ見えないので、次の手順で権限セットを付けます。
3. 権限セットライセンスと権限セットを付ける
- 作った連携ユーザーの詳細画面を開きます。
- 「権限セットライセンスの割り当て」の関連リストで「割り当てを編集」をクリックします。
- 「Salesforce API Integration」にチェックを入れ、「保存」をクリックします。
- 「設定」の「クイック検索」に「権限セット」と入力し、「権限セット」を開きます。
- 「新規」をクリックし、「表示ラベル」に「連携_会計ソフト」と入力します。
- 「ライセンス」で「Salesforce API Integration」を選び、「保存」をクリックします。
- 「オブジェクト設定」を開き、商談と取引先に「参照」、導入プロジェクトに「参照」と「編集」を付けます。
- 同じ画面で、会計ソフトが読む項目（金額、完了予定日、値引き率など）の項目レベルセキュリティに「参照アクセス権」を付けます。
- 「割り当ての管理」から連携ユーザーにこの権限セットを割り当てます。
付けすぎないのが要点です。会計ソフトは商談を読むだけ、書くのは導入プロジェクトの一部の項目だけ、と絞っておけば、相手側に問題が起きても被害は狭く止まります。「すべてのデータの編集」は、データ移行のような一時的な作業以外では付けません。
4. 外部クライアントアプリケーションを作る
外部のサービスにSalesforceへの入り方を教えるのが、外部クライアントアプリケーションです。以前は「接続アプリケーション」の役割でしたが、Spring ’26 から新しい接続アプリケーションの作成が制限されました。既存のものはそのまま動き、新しく作るものは外部クライアントアプリケーションにします。Professional・Enterprise・Performance・Unlimited・Developer Edition で作れます。
- 「設定」の「クイック検索」に「アプリケーションマネージャー」と入力し、「アプリケーションマネージャー」を開きます。
- 右上の「新規アプリケーション」の▼から「新規外部クライアントアプリケーション」を選びます。
- 外部クライアントアプリケーション名に「会計ソフト連携」と入力します。
- API 参照名が「会計ソフト連携」のままでは使えないので、「Accounting_Integration」に書き換えます。
- 「取引先責任者メール」に、管理者の共有アドレスを入力します。
- 「配信状態」を「ローカル」にします。
- 「API (OAuth 設定の有効化)」の「OAuth を有効化」にチェックを入れます。
- 「コールバック URL」に、会計ソフト側から指定されたURLを入力します。
- 「OAuth 範囲」で「API を使用してユーザーデータを管理 (api)」を「選択した OAuth 範囲」に移します。
- 相手側がユーザーの操作なしでつなぐ方式なら「フローの有効化」の「クライアントログイン情報フローを有効化」にチェックを入れ、確認のメッセージで「OK」をクリックします。
- 「作成」をクリックします。
保存するとコンシューマー鍵とコンシューマーの秘密が発行され、これを会計ソフト側の画面に入れると接続できます。この2つを持つ人やシステムは誰でもアクセストークンを取れるので、チャットやメールに貼らず、相手側の画面に直接入れます。漏れた疑いがあれば、すぐに秘密を作り直します。
5. 誰として動くかと、使える人を決める
外部クライアントアプリケーションには「設定」と「ポリシー」の2つのタブがあります。設定はアプリの作りで、ポリシーは自社でどう使わせるかです。
- 「設定」の「クイック検索」に「外部クライアントアプリケーションマネージャー」と入力し、「外部クライアントアプリケーションマネージャー」を開きます。
- 「会計ソフト連携」をクリックして詳細ページを開きます。
- 「ポリシー」タブを開きます。
- 「編集」をクリックします。
- 「OAuth ポリシー」の「許可されているユーザー」で「管理者が承認したユーザーは事前承認済み」を選び、確認のメッセージで「OK」をクリックします。
- 「権限セットを選択」で、「連携_会計ソフト」を「選択済みの権限セット」に移します。
- 「クライアントログイン情報フローを有効化」にチェックを入れ、「(ユーザー名) として実行」に、手順2で作った連携ユーザーのユーザー名（メール形式）を入力します。表示名の「連携 会計ソフト」では受け付けられません。
- 「保存」をクリックします。
クライアントログイン情報フローでは、外部サービスは常に実行ユーザーの権限で動きます。ここに管理者を入れると、相手側から組織の全データが読めてしまいます。使い始めた後は「外部クライアントアプリケーションの OAuth 利用状況」で生きているトークンを確認でき、連携先の解約時はここでまとめて取り消します。
6. API 使用状況通知を入れる
- 「設定」の「クイック検索」に「API 使用状況通知」と入力し、「API 使用状況通知」を開きます。
- 「新規」をクリックします。
- 「通知受信者」に管理者を選びます。
- 「しきい値」に「80」と入力します。
- 「通知間隔 (時間)」に「24」と入力します。
- 「保存」をクリックします。
この機能は Enterprise・Performance・Unlimited・Developer Edition で使え、「すべてのデータの編集」権限が要ります。Professional では、手順1の「システムの概要」を週に一度見る運用で代わりにします。
7. Salesforce から外へ送る側の準備（指定ログイン情報）
逆向きに、Salesforceのフローや Apex から外部のAPIを呼ぶときは、「外部ログイン情報」に認証方式と鍵を、「指定ログイン情報」に呼び出し先のURLを入れてつなぎます。外部ログイン情報が先で、そのあと外部ログイン情報の「プリンシパル」を権限セットに結び付け、その権限セットを持つユーザーだけが外へ送れるようにします。指定ログイン情報は全エディションで使えます。
これを使うと、フローの「HTTP コールアウト」アクションからコードを書かずに外部APIを呼べます（「アプリケーションのカスタマイズ」権限が必要）。フローの組み方は「Salesforceフローの作り方。レコードトリガーで更新と通知を自動化する」で説明しています。
APIの種類
管理者が覚えておくのは、どれがデータ用で、どれが設定用かの区別だけです。
| API | 何に使うか |
|---|---|
| REST API | レコードの作成・参照・更新・削除。連携ツールの多くがこれを使う |
| SOAP API | REST API と同じくレコードの読み書き。基幹システムとの古い連携で多い |
| Bulk API 2.0 | 2,000件を超える大量のレコードの読み込み・書き込みを非同期で処理する |
| Pub/Sub API | レコードの変更やプラットフォームイベントを外部へ流し続ける |
| ストリーミング API | 変更の通知を受け取る旧来の仕組み。新しく作るなら Pub/Sub API を勧められている |
| メタデータ API | 項目・レイアウト・フロー・Apexなど、設定そのものの取得とリリース |
| Apex REST・Apex SOAP | 開発者が書いた Apex を外部から呼べる窓口にする |
データローダもAPIを使うので、APIが使えない契約では使えません（「データローダの使い方。インストールから一括更新・削除まで」）。連携ツールに「バルク」の切り替えがあれば、件数の多い同期ではそちらを選ぶと呼び出し回数が減ります。
管理者が Salesforce CLI を入れれば、SOQL（データを問い合わせる言語）で組織のデータを直接引けます。完了予定日を過ぎても進行中のままの導入プロジェクトを、取引先名と一緒に出すには次のように書きます。
SELECT Name, Account__r.Name, Status__c, Planned_End_Date__c, Days_Late__c
FROM Implementation_Project__c
WHERE Status__c = '進行中' AND Days_Late__c > 0
ORDER BY Days_Late__c DESC撮影用の組織では7件が返り、先頭は遅れ47日の「ことぶき食品 請求業務の効率化 導入」でした。__r を付けると親の取引先の項目を読めます。連携先に「この条件のデータを送ってほしい」と伝えるとき、SOQLで書いて渡すと誤解が起きません。
Apexとは何か、フローで済ませるかの判断
Apexの位置づけ
Apex は Salesforce の中で動くプログラム言語で、保存の前後に動く「トリガー」と、処理をまとめた「クラス」の形で組織に保存されます。使えるのは Enterprise・Performance・Unlimited・Developer Edition（と Database.com Edition）で、Starter・Pro Suite・Professional では書けません。書かなくても、読めると受け入れが楽になります。トリガーの骨組みはこれだけです。
trigger ImplementationProjectTrigger on Implementation_Project__c (before update) {
for (Implementation_Project__c p : Trigger.new) {
Implementation_Project__c old = Trigger.oldMap.get(p.Id);
if (p.Status__c == '完了' && old.Status__c != '完了' && p.Completed_Date__c == null) {
p.Completed_Date__c = Date.today();
}
}
}(before update) は「導入プロジェクトが更新され、保存される直前に動く」という意味で、ほかに after insert や after undelete なども指定できます。Trigger.new には一度に保存されるレコードがまとめて入るので、ループで回します。なお、この「完了になったら完了日を入れる」は本来フローで作るもので、骨組みを見せるための例です。
フローで済ませる範囲とApexが要る場面
Salesforce のアーキテクト向けの判断ガイドは、オブジェクトに乗る自動化の数で道具を選ぶよう勧めています。15未満で1回の件数が200件程度までならレコードトリガーフロー、15〜30ならフローを入口に重い計算だけ Apex、30を超えるか数千件単位の一括処理が日常ならApexトリガー中心、という目安です。営業6名の組織はほぼ全部フローの範囲で、迷ったら次の表で判断します。
| やりたいこと | フローで足りるか | Apexが要る理由 |
|---|---|---|
| 同じレコードの項目を保存前に書き換える | 足りる | 不要 |
| 商談の受注で導入プロジェクトを作る | 足りる | 不要 |
| 条件に合わないとき保存を止めてメッセージを出す | 足りる（カスタムエラー） | 項目ごとに細かく出し分けるならApex |
| 外部APIにデータを送る | HTTP コールアウトで足りることが多い | 認証が特殊、応答の加工が複雑なとき |
| ごみ箱から戻したときに動かす | 足りない | 復元（undelete）はApexトリガーでしか拾えない |
| 途中で失敗したら全部を元に戻す、一部だけ保存する | 足りない | トランザクションの細かい制御はApexだけ |
| 数千件を一度に入れて複雑な計算をする | 向かない | 大量件数の重い処理はApexが推奨 |
同じオブジェクトに、フローと Apex トリガーの両方を入口として置かないことも判断ガイドに書かれています。両方あると、どちらが先に何を書き換えたかを追えなくなるので、オブジェクト単位で入口を1つに決めます。
Visualforce と Lightning Web コンポーネント
Visualforce は、HTML に似た書き方で独自の画面を作る古い仕組みです。Professional Edition を含む多くのエディションで今も動きますが、新しい画面をこれで作る理由はほとんどなく、古いページが Lightning Experience で崩れていないかだけ見ておけば足ります。
Lightning Web コンポーネント（LWC）は、今の Lightning Experience の画面部品を作る仕組みです。開発者が作ったコンポーネントは Lightning アプリケーションビルダーの部品一覧に並び、管理者がドラッグして画面に置けます。ただし自動では並ばず、開発者側の設定が要るので、発注時に「Lightning アプリケーションビルダーで配置できる形で」と入れておきます。
Apexを本番に入れるときの決まり
本番では直接書けない
Apex は本番組織の画面では追加も編集もできず、画面から書けるのは Developer Edition、Enterprise Edition のトライアル、sandbox だけです。本番へはメタデータ API を使ったリリース（Salesforce CLI、変更セットなど）で入れます。運用としては、sandboxで作って確かめてからリリースする形が現実的です。sandboxの作り方は「Salesforceのsandboxの作り方と使い分け。本番を壊さずに試す」で扱っています。
テストとコードカバー率の条件
本番へのリリースでは、次の条件を全部満たさないと止まります。
| 条件 | 内容 |
|---|---|
| コードカバー率 | 組織の Apex の75%以上が単体テストで実行されている |
| トリガー | すべてのトリガーが何らかのテストで実行されている |
| テスト結果 | すべてのテストが成功している |
| コンパイル | すべてのクラスとトリガーが正常にコンパイルされる |
テストクラス自体と System.debug の行はカバー率に入りません。sandbox と Developer Edition にはカバー率の制限がかからないので、sandboxで動いたことは本番に入れられる証明になりません。公式ヘルプも、数字を追うより正常・異常、1件・複数件の両方をテストするよう勧めています。テストクラスの骨組みは次のとおりです。
@isTest
private class ImplementationProjectTriggerTest {
@isTest
static void setsCompletedDateWhenStatusIsCompleted() {
Account a = new Account(Name = 'テスト取引先');
insert a;
Implementation_Project__c p = new Implementation_Project__c(
Name = 'テスト導入', Account__c = a.Id, Status__c = '進行中');
insert p;
p.Status__c = '完了';
update p;
p = [SELECT Completed_Date__c FROM Implementation_Project__c WHERE Id = :p.Id];
System.assertEquals(Date.today(), p.Completed_Date__c);
}
}最後の System.assertEquals が結果を確かめている行です。これが無く、レコードを作って更新するだけのテストは、カバー率を満たしても中身を何も確かめていません。受け入れで見るのはそこです。
変更セットで入れるときの流れ
変更セットなら、本番側の「受信変更セット」で先に「検証」をクリックし、リリースせずにテストとカバー率の結果だけを確かめます。検証が通れば「クイックリリース」の対象になります。リリースは1つのトランザクションで、途中で失敗すれば全部元に戻りますが、成功後に取り消す機能はなく、戻すには前の版を入れ直します。送信側でアップロードした変更セットは6か月で消えます。
Apexの動く権限が変わる点
Apex の概要ページによると、API バージョン67.0以降の Apex はデータベース操作が既定で実行中のユーザーの権限と項目レベルセキュリティに従います（66.0以前はシステムの権限が既定）。新しいApexが営業のユーザーでは項目を読めずに止まることがあるので、どのユーザーの権限で動く前提かを最初に決めておきます。
応用
外部の開発会社に頼むときに決めておくこと
発注の前に次を決めて渡しておくと、納品後の手戻りが大きく減ります。実際に回っている会社では、この表を見積もり依頼に付けています。
| 決めること | 決め方の例 |
|---|---|
| 連携ユーザー | 連携ごとに1ユーザー。管理者が作り、開発会社には渡さず権限セットで絞る |
| 触ってよい項目 | 読む項目と書く項目をオブジェクトごとに列挙する。それ以外は付けない |
| エラー時の連絡 | 失敗時のメールの宛先は共有アドレス。自動で再送するか、通知して人が直すか |
| 呼び出し回数 | 1日に何回APIを呼ぶ見込みか。上限の何割に収まるか |
| 作業環境とテスト | sandboxで作り、正常・異常・複数件のテストを含める |
| 引き継ぎ資料 | 何がどの順に動くか、止めるときはどこを無効にするか |
開発会社に本番の管理者権限を渡す運用は、契約終了後の権限の回収漏れにつながるので避けます。
チャットとの連携は標準機能から
「商談の更新をチャットに流す」連携は、Slack なら標準の連携機能とフローで作れ、APIの契約も Apex も要りません（「SalesforceとSlackの連携。商談の更新をチャンネルに流す」）。
できないことと、その代わり
- Professional Edition は標準ではAPIが使えません。有償の「Web Services API」を追加するか、認定を受けた AppExchange のアプリを選びます。追加のAPI呼び出しを買うだけでは有効になりません。
- Starter・Pro Suite・Professional では Apex を書けません。AppExchange のアプリで埋めるか、Enterprise 以上に上げます。
- 新しい接続アプリケーションは原則作れません。相手の手順書が接続アプリケーション前提でも、外部クライアントアプリケーションで同じ値を設定します。
- 24時間のAPI上限は設定では増やせません。ライセンスか追加のAPI呼び出しを購入するか、連携側の読み方を変えて減らします。
- フローは、ごみ箱からの復元に反応できず、トランザクションを途中まで保存する制御もできません。この2つが要るときだけ Apex にします。
よく詰まるところ
| 症状 | 原因 | 直し方 |
|---|---|---|
| 連携ツールで「API is not enabled for this Organization or Partner」 | Professional でAPIを追加していない、またはユーザーに「API の有効化」が無い | システムの概要でAPI使用状況を確認し、契約か権限を直す |
| 連携ユーザーで導入プロジェクトが0件に見える | Minimum Access のプロファイルはほぼ何も見えない | 権限セットでオブジェクト権限と項目の参照権限を付ける |
| 「新規接続アプリケーション」が見当たらない | Spring ’26 からの作成制限 | アプリケーションマネージャーで外部クライアントアプリケーションを作る |
| sandboxを作り直したら連携が動かない | ローカルの外部クライアントアプリケーションはsandboxにコピーされない | sandbox側で作り直し、新しい鍵を入れる |
| 夕方に連携が止まり、翌朝には直っている | 24時間のAPI上限に達した | 使用量を見て、多い連携の取得間隔を延ばすか Bulk API に切り替える |
| 連携が「REQUEST_LIMIT_EXCEEDED」で断続的に失敗する | 20秒以上かかる要求の同時実行が上限に達した | 重いクエリを分ける、同時に走らせる連携の時間をずらす |
| sandboxでは通ったのに本番リリースがカバー率不足で失敗する | 本番では組織全体のカバー率で判定される | 本番で全テストを実行して低いクラスを探し、テストを足して検証からやり直す |
| Apexのリリースが失敗する（スケジュール済みのジョブあり） | 待機中・処理中のApexジョブが対象を使っている | ジョブを止めてリリースし再スケジュールする。または「リリース設定」で許可する |
| 保存後に項目が想定と違う値になる | 同じオブジェクトにフローとApexトリガーがあり、順番が読めない | 入口をどちらかに寄せる |
| フローの HTTP コールアウトで権限エラーになる | 外部ログイン情報のプリンシパルが権限セットに結び付いていない | 外部ログイン情報のプリンシパルを、動かすユーザーの権限セットに追加する |
次にやること
準備ができたら、まずフローで足りる自動化を組み、Apexに回すものを絞ります。続けて読むのは次の4本です。
- Salesforceフローの作り方。レコードトリガーで更新と通知を自動化する
- データローダの使い方。インストールから一括更新・削除まで
- Salesforceのsandboxの作り方と使い分け。本番を壊さずに試す
- SalesforceとSlackの連携。商談の更新をチャンネルに流す