ロード中の自動化

🌐 ほかに 19 言語で読めます

English · Español · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI で生成した画像

このページはAIで翻訳されています。コミュニティによるレビューはまだ行われていません。 英語で読む このセクションは英語版が更新されたため、まだ再翻訳されていません。 (61)

モジュール3／5：Data Architectコース第10章「移行と同期」。各モジュールは単独でも読めます。 前へ：大量のロード · 次へ：切り替えの週末

このモジュールが答える問い： 移行のデータをロードしている間、Salesforceの自動化はどうあるべきか？

RouteDesk’s records are ready: about 707,000 of them, prepared, sorted by parent, rehearsed. You start the load, and Salesforce starts doing exactly what you configured it to do. Flows fire, triggers run, validation rules evaluate, emails send, tasks get created, rollups calculate, integrations launch, events publish. Your 707,000-record migration isn’t performing 707,000 operations anymore. It’s performing 707,000 records multiplied by everything each record causes. That’s a different migration. ⟲

Start With the Picture

Here’s the landscape again, the weekend RouteDesk retires. The migration arrow is amber. Now look at what else leaves Salesforce when a Work Order is created or changes status. ⟲

クリックで拡大

One arrow in. Three more arrows out, for every record, unless we decide otherwise. ⟲

Every one of those arrows was designed in chapter 9 for a delivery that just happened: a status changed, so tell the partner and Snowflake; a delivery finished, so count it for invoicing; a delivery is tomorrow, so text the Recipient. The load creates 196,400 Work Orders in one weekend, and about 190,000 of them arrive already completed. To the automation, each one looks like a delivery that just happened. ⟲

自動化は、それが移行だとは知らない

Salesforce sees a record transaction. It doesn’t know “this is historical data loaded during a controlled cutover.” A flow sees a new Account and does what it was built to do: creates an onboarding task, sends a welcome email, publishes an event, updates a related record, calls another system. Correct when a sales rep creates one account on Tuesday afternoon. Completely wrong when a migration creates 800,000 historical accounts on Saturday night. Same operation, different business context. At Steve Trucking, a Work Order arriving with a status of Completed looks exactly like a crew finishing a delivery five minutes ago. ⟲

だから大きな移行では、私はここから始めます。通常の業務の自動化は、**ロードに対してやみくもに動くべきではない。**それは「全部止める」という意味ではありません。重要な自動化の一つひとつに意図した判断を下すということで、本番が40万通のメールを送ったせいで答えがわかる、という形にはしたくないのです。

3つの選択：不要にする、模擬する、延期する

For each automation, I ask what it does and what happens if it doesn’t run, and then I put it in one of three categories. ⟲

**不要にする（なくす）。**その振る舞いは移行したレコードには起きるべきではありません。8年来の顧客に「当社へようこそ！」は要りません。取引先を1件挿入すればメールが1通送られ、100万件ロードすれば、100万通のメールは要りません。

**模擬する。**自動化は動くべきではないが、それが生む結果は今も必要。取引先の作成時に動くフローが顧客区分を導き出すとします。移行した取引先にも有効な区分が必要ですが、フロー全体を500万回動かすのは高くつくか、副作用があります。だから変換の中で区分を計算し、その結果をロードします。ビジネスルールを無視したのではありません。自動化の仕事をロードの中でやったのです。

**延期する。**結果は必要だが、ロードのトランザクションの中でなくてよい。自動化を止め、フラグを立ててロードし、そのあとバッチ処理を起動して追いつかせます。再計算し、依存するレコードを作り、その先のシステムが必要とするものを発行する。延期すれば、結果をあきらめずに、ロードをより速く、より管理しやすくできます。

そして動かしたままにすることもあります。小さめのロードで、ビジネスが通常のプロセスを動かしたいなら、システムにいつもどおりのことをさせましょう。それも選択です。選択である限りは。

何を選ぶにせよ、私が教えるルールはこれです。**自動化を止めるたびに、そのビジネスロジックが起きないことに全面的に責任を持つことになる。**決める前に、すべての自動化を理解する必要があります。

クリックで拡大

Three questions, four answers, one decision per automation. ⟲

Test knowledge. For each automation on a large load, decide: not needed for migrated data (bypass it), needed but its result can be set in the data (simulate it in the transformation), needed but not inside the load (defer it to a batch afterward), or needed inside the load (let it run). Expect a scenario where blindly running automation creates unwanted emails, tasks or integration calls, and one where turning it off silently loses a required result. ⟲

「自動化を無効にする」は戦略のすべてではない

計画には「自動化を無効にする」とあります。どの自動化を？　どうやって、誰が、いつ？　止まっていることをどう知り、また動いていることをどう知るのか？　通常それが生む結果のうち、あとでどれが存在していなければならないのか？　止まっている間にユーザーがシステムにいたら、あるいは移行が途中で失敗したら何が起きるのか？　何かを止めるのは運用上の操作です。アーキテクチャには、ライフサイクル全体が必要です。通常の状態、移行の状態、通常への復帰、そして戻ったことの証明。

And before you decide what to switch off, find out what’s still switched on. Old automation runs on migrated records too. Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025, but “your active Workflow Rules and Process Builder processes continue to run as they did before” (ワークフロールール & プロセスビルダーのサポートの廃止 （新しいタブで開きます）, Salesforce Help, checked 2026-10-27). Well-Architected points out the cost: an org “carrying dozens of Process Builders left over from prior implementations … pays to evaluate every one of them on every relevant record save,” and its advice is to “migrate remaining Process Builders to Flow; don’t just deactivate them” (Resource and Cost Optimization （新しいタブで開きます）, checked 2026-10-27). A migration is a good reason to clear them out first, so 707,000 records aren’t run through automation nobody remembers. ⟲

Build the Bypass In From the Start

私のより強い立場はこうです。**重要な自動化には、移行の予定がなくても、管理されたバイパスを持たせるべきだ。**それが必要になる理由は移行だけではありません。大きな修正、データの訂正、さかのぼっての埋め直し、統合の修復、緊急の復旧。通常の自動化のすべてを動かさずに、管理された操作を実行しなければならないことがあります。唯一の方法が本番でフローを編集すること、トリガーを無効にすること、入力規則を削除することなら、運用の仕事を不必要に危険にしてしまっています。そして本番でトリガーを単純に止めることはできません。それはテストを伴うデプロイです。

The standard answer is a bypass (some teams call it a kill switch): the first thing the trigger or flow does is check a switch, and skip itself if the switch is on. Decide the scope: a global switch for the whole org, one per object, one per automation, or one for particular users, such as the data load user or anyone holding a permission. Put it in your flows as well as your triggers. Flows are easy to deactivate, but a user-specific switch lets everyone else keep working. I consider flows visual programming: whether you’re writing code or programming visually, you’re still programming, and programs need this. ⟲

And here’s the part teams miss: the bypass is part of the original design. It isn’t something you build the week you need it. Every trigger and flow gets its bypass when it’s first built. It’s tested both ways, switched on and switched off, like any other behavior. And it goes to production with the automation, long before any migration, so on cutover weekend it’s already there, already tested, and ready to switch on. A bypass written in a hurry for the load is new, untested code going into production on the riskiest weekend of the project. Salesforce’s Record-Triggered Automation decision guide is just as firm: “A well-architected Salesforce organization requires a consistent and reliable mechanism to bypass automation. This is not an optional feature, but a core operational requirement” (Record-Triggered Automation （新しいタブで開きます）, Salesforce Architects decision guide, checked 2026-10-27). ⟲

Salesforce says the same thing in its own words. Its Well-Architected list of automation anti-patterns includes “Flows must be manually deactivated prior to bulk data loads” (Automation Patterns （新しいタブで開きます）, Operational Excellence, checked 2026-10-27). If your load plan says “deactivate these twelve flows on Friday night,” that’s the anti-pattern. ⟲

Test knowledge. Build a bypass into triggers and flows when they’re first built (a check of a custom permission, a custom setting or custom metadata at the start), test it on and off, and deploy it ahead of time, so large loads can skip them without editing or deactivating anything in production. Scope it: by object, by automation, or by user, such as the migration user. Deactivating flows by hand before a bulk load is an anti-pattern in Salesforce’s own Well-Architected guidance. ⟲

What a Bypass Looks Like

So what does a bypass actually look like? Three parts: a place to keep the switch, a check at the top of every trigger and flow, and the same check in the validation rules you decide to relax. Salesforce gives you three places to keep it, and each one decides who the switch applies to. ⟲

Where the switch lives	Who it applies to	Good for
A custom permission, granted by a permission set	Only the users who hold it	The usual migration bypass: give it to the migration user for the load, take it away after
A hierarchy custom setting	The whole org, one profile, or one user	A global “automation off” for everyone, or a switch for one profile or one user
A custom metadata record per automation	Everyone, for that one automation	Switching off one specific automation, deployed and versioned like code

The hierarchy custom setting is the one that does global, profile and user in one place. Salesforce’s description: it “checks the organization, profile, and user settings for the current user and returns the most specific, or lowest, value” (Define Custom Settings （新しいタブで開きます）, Salesforce Help, checked 2026-10-27). Set it off for the org, on for the migration user, and the migration user gets the bypass while everyone else gets normal automation. For most other configuration Salesforce now steers you to custom metadata instead, which deploys with your code; I’d use that for the per-automation switches. ⟲

In Apex, the check is the first thing the trigger does. Here’s what it could look like on the Work Order, with a hierarchy custom setting called Automation_Bypass__c and a custom permission called Bypass_Automation: ⟲

trigger WorkOrderTrigger on WorkOrder (after insert, after update) {
    // The hierarchy custom setting: the user's value, else the profile's, else the org's
    Automation_Bypass__c settings = Automation_Bypass__c.getInstance();

    // Bypass if the setting says so, or if this user holds the custom permission
    Boolean bypass = settings.Disable_Triggers__c == true
        || FeatureManagement.checkPermission('Bypass_Automation');

    if (bypass) {
        return;   // no side effects; the record still saves
    }

    WorkOrderStatusOut.publish(Trigger.new, Trigger.oldMap);
}

getInstance() returns the setting “for the current user,” merged from the lowest level that’s defined (Custom Settings Methods （新しいタブで開きます）), and FeatureManagement.checkPermission “checks whether a custom permission is enabled” (FeatureManagement Class （新しいタブで開きます）; both Apex Reference Guide, Winter ‘27, checked 2026-10-27). ⟲

And one switch per automation, so the bypass is scoped instead of “skip everything.” A custom metadata type, Automation_Switch__mdt, with one record per automation: ⟲

public with sharing class WorkOrderStatusOut {
    public static void publish(List<WorkOrder> orders, Map<Id, WorkOrder> oldOrders) {
        // One record per automation; switched off here, it's off everywhere it's deployed
        Automation_Switch__mdt sw = Automation_Switch__mdt.getInstance('WorkOrder_Status_Out');
        if (sw != null && sw.Is_Off__c) {
            return;
        }
        // ... publish the status change for the partners
    }
}

getInstance(developerName) reads one custom metadata record by its name (Custom Metadata Type Methods （新しいタブで開きます）, Apex Reference Guide, checked 2026-10-27). ⟲

In a flow, it’s the same idea: the first element is a decision. ⟲

クリックで拡大

The check comes first. Switched on, the flow steps aside. ⟲

The decision’s condition reads the same two switches, through flow’s global variables: $Permission is “the custom permission access of the user running the flow,” and $Setup reads hierarchy custom settings (Global Variables Resource （新しいタブで開きます）, Salesforce Help, checked 2026-10-27). As a formula resource: ⟲

{!$Permission.Bypass_Automation} || {!$Setup.Automation_Bypass__c.Disable_Flows__c}

In a validation rule, the bypass is one more condition. Here’s R12’s install rule, with the migration user allowed through (the field names are examples): ⟲

AND(
  NOT($Permission.Bypass_Automation),
  ISPICKVAL(Status, "Completed"),
  Install_Required__c,
  NOT(Install_Checklist_Complete__c)
)

Validation rules reference a custom permission as $Permission.Custom_Permission_Name (「数式」、「ワークフロールール」、または「入力規則」の中で「権限セット」を参照する （新しいタブで開きます）, Salesforce Help, checked 2026-10-27). ⟲

Salesforce’s decision guide calls custom permissions “the modern, scalable standard for implementing bypass logic,” and notes a bypass can be granted to one user, “or even temporarily with a specific expiration date/time” (Record-Triggered Automation （新しいタブで開きます）, checked 2026-10-27). That’s the migration window, built into the grant. ⟲

These are examples to adapt, not a framework to paste in: build yours, test it in a sandbox, and test that the switch turns back off. And remember what you’ve built. A bypass is a permission to skip business rules. Grant it to the migration user for the migration window, record who has it, and take it away when the load is done (module 4 puts that in the runbook). ⟲

Test knowledge. Know the three places to keep a bypass and who each applies to: a custom permission (only the users whose permission sets grant it; checked with $Permission in flows and validation rules, FeatureManagement.checkPermission in Apex), a hierarchy custom setting (the org, a profile or a user, the most specific value winning; $Setup in flows and formulas, getInstance() in Apex), and custom metadata (one switch per automation, deployable). ⟲

バイパスは「全部飛ばす」ではない

バイパスは、移行用ユーザーがSalesforceのすべてのルールを無視するという意味ではありません。ある自動化は飛ばすべきでも、別のものは動かなければならない。根本的な不変条件を守る入力規則は今も重要で、通知はそうではない。その先の統合は抑えるべきでも、必須のリレーションは確認する必要がある。だから私は、意図して範囲を絞ったバイパスが欲しいのです。Migration_Mode__c = trueだから何も関係ない、ではなく。移行の道筋にもルールはあります。移行にふさわしいルールだけが。

そしてバイパスは、偶然ではなく運用の文脈を表すべきです。専用の移行用の身元（モジュール2）、カスタム権限、設定のメタデータ、機能フラグ、あるいはその組み合わせで、承認された移行の作業を見分けられます。身元を制御の一部にしてもかまいませんが、すべての自動化にUser.Name = 'Migration User'をハードコードするのは嫌です。壊れやすいからです。意図を表しましょう。これが承認された移行の操作なら、この副作用を飛ばす、と。

入力規則には判断が要る

「商談がClosed Wonなら完了予定日は必須」は本物のデータの不変条件で、過去の商談でも残すべきです。3年前に導入した現行プロセスの項目を必須にするルールは別物です。10年前のレコードはそれを持ったことがなく、値をでっち上げればデータを悪くします。問いは「入力規則を止めるか？」ではありません。**どのルールが永続するデータの真実を表し、どれが今日の対話的なプロセスを表しているのか？**です。それはデータアーキテクトの問いです。

Steve Trucking has one of each. Every Work Order must have a Retail Partner: that’s enduring truth, and it stays on for the load; a RouteDesk delivery without one goes to quarantine (module 1). But requirement R12 says an install can’t be closed without a completed checklist and specific photos, the water line, the drain line, the level. That’s today’s process, built for crews with the new mobile app. RouteDesk’s completed installs never had those photos. Bypass that rule for the migration identity, and load them as completed. Don’t invent photos. ⟲

気をつけたい兆候があります。ターゲットは値を求め、ソースにはそれがない。だから「全部に’Unknown’を入れておけ」。Unknownが承認された値で、本当にその状態を表しているならかまいません。入力規則を通すために偽の値を入れているなら、アプリケーションを満足させるためにデータを壊しています。知らないことを知っているふりをするより、移行の例外、nullを許す履歴の項目、変換のルール、レガシーの状態の値を設計したいのです。

自動化はゼロの数を掛け算する

200万件の取引先をロードし、自動化がそれぞれに2件のタスクを作れば、400万件のタスクです。意図したものか、事故か？　次にそれぞれのタスクが別のフローを動かし、取引先の自動化は親を更新し、イベントを発行し、さらに別のものを再計算する。移行の性能は、Bulk APIが取引先をどれだけ速く挿入するかではありません。本当の作業量は、その挿入が生み出すトランザクションのグラフです。ゼロの数は自動化を通じて掛け算されます。

Now zoom in on RouteDesk’s three red arrows and count. ⟲

クリックで拡大

Every record, times everything it sets off. ⟲

Chapter 9 turned on Change Data Capture for Work Orders, so Snowflake’s subscriber receives a change event for every create. That’s about 196,400 events in one weekend, and without an add-on the daily allocation for delivered events is 50,000 in Performance and Unlimited Editions, counted per subscriber (Change Data Capture Allocations （新しいタブで開きます）, checked 2026-10-27). The partners would get status messages for about 190,000 deliveries they closed weeks ago. The finance ERP would count deliveries it has already invoiced, and the partners would be billed twice. And Recipients would get texts about deliveries that already happened. ⟲

クリックで拡大

Keep only the outcomes you need: one backfill, texts for the open deliveries, nothing to partners or finance. ⟲

外部への副作用はもっと悪い。顧客へのメール、請求の依頼、本番のシステムが消費するイベント、ERPの呼び出し、サポートのチケット、マーケティングの更新。それらのシステムは移行のデータだとは知らず、メッセージがSalesforceを出てしまえば、取り消せないかもしれません。第9章は統合のデータ契約をくれました。移行の計画の間に、それらの矢印のうちどれを動かしてよいか、どれを抑えるか、どれを切り替えのあとの同期に置き換えるかを決めましょう。その判断は切り替えの計画に入れます。

派生データ、共有、ステージングオブジェクト

積み上げ集計などの派生した値。親をロードし、次に何百万件もの子をロードして、子のたびに再計算しますか？　そうかもしれません。でも多くの場合、すべてをロードしてから一度だけ計算するほうがはるかに安上がりです。問いは、派生した結果を移行の間レコードごとに維持しなければならないのか、依存するデータがそろってから確定すればよいのかです。それは、不要にする／模擬する／延期するの判断と同じです。

共有も派生データです。レコードの作成や移転は共有ルールの計算を引き起こし、大きなロードでは非常に長い評価やタイムアウトにつながることがあります。Salesforceでは管理者が共有の計算を延期し（共有ルールとグループのメンバーシップ）、あとで再開できますが、この機能は既定では有効ではなく、Salesforceサポートが有効にします。再開するときは完全な再計算を実行しなければならず、データの整合性を守るために、一部の共有の変更はやはりすぐに計算されます（Defer Sharing Calculations （新しいタブで開きます））。計画し、再計算の時間も計画しましょう。

Deferring has limits of its own. The catch-up usually runs as batch Apex, and that shares the org’s daily allowance of asynchronous Apex executions: “250,000 or the number of applicable user licenses in your org multiplied by 200, whichever is greater.” Only five batch jobs can be queued or active at once, with up to 100 more waiting in the flex queue (Execution Governors and Limits （新しいタブで開きます）, Apex Developer Guide, Winter ‘27, checked 2026-10-27). Your catch-up competes with every other batch job in the org, so schedule it, and size it. ⟲

Test knowledge. Large loads trigger sharing recalculation. Salesforce Support can enable deferred sharing calculations (sharing rules and group membership), which you resume and recalculate after the load. Deferred work usually runs as batch Apex, within the daily asynchronous Apex limit and five concurrent batch jobs. ⟲

And sometimes the logic you need is simply too slow to load through. This is the special case module 1 mentioned. A process that takes a second or two per record is fine for users; for hundreds of thousands of records in a cutover window it means days, and trying to simulate an intricate object model in the load can mean a dozen tables. The technique I use: load into a staging object first, a light custom object with no automation that holds the import fields and lookups, then let a batch process work through it, calling the platform’s own logic to build the real records. The status on each staging row lets the batch work in chunks, pause and resume, and the original import fields stay alongside the records they created for tracing. You get the data in fast and catch up on the processing afterward. ⟲

最終的な状態に向けて設計し、書き留める

目標は「本番の自動化を動かす」ことではありません。正しい本番の状態にたどり着くことで、両者は同じではありません。新しい取引先の通常の処理は、分類を導き、オンボーディングのタスクを作り、通知を送り、別のシステムに発行します。移行した過去の取引先にとって正しい最終的な状態は、分類は要る、オンボーディングのタスクは要らない、歓迎の通知は要らない、外部への発行は同期の計画次第で要るかもしれない、かもしれません。通常の自動化をやみくもに動かせば、移行のために設計されていないプロセスを再現することになります。

本格的な移行では、自動化の一覧として書き留めましょう。

自動化	通常の振る舞い	移行での判断	移行で必要な結果
Status out to partners	Send each status change to Redrock, Keystone, Brightwave	Don’t need it	None: the partners already have it
Change Data Capture to Snowflake	A change event per Work Order	Defer	One backfill of status history after the load
Delivery counts to finance	Count each completed delivery for invoicing	Don’t need it	None: already invoiced; reconcile the count instead
Day-before text	Text the Recipient with a tracking link	Run deliberately, open deliveries only	Monday’s Recipients get the link; none for delivered ones
Work Order status	Set by the crews’ app	Simulate	Status mapped in the preparation data store
Install checklist and photos (R12)	Block closing an install without them	Bypass for the migration identity	Completed installs load as completed; no invented photos
Every Work Order has a partner	Reject a Work Order without one	Keep	Missing partner: quarantined before the load

これで判断が見えるようになります。レビューし、テストし、リハーサルし、ロードのあとに検証できます。

バイパスをリハーサルし、それから元に戻す

本番を、移行モードを使う最初の機会にしないこと。リハーサルでは、移行用の身元、バイパスの制御、動いたままの自動化、模擬した結果、延期したプロセス、通常モードへの復帰をテストし、それから確かめます。起きるべきでないことが起きたか、起きるべきことが起きなかったか、最終的な状態はアーキテクチャと一致するか？　だからリハーサルには本物の自動化の設定、あるいは実用上できるだけ近いものが必要なのです。

元に戻すのは切り替えのステップです。明示的で、名前のある責任者、予定の時刻、検証を伴います。「フローを戻すのを忘れないように」ではありません。通常の運用が戻り、検証されるまで、システムはユーザーを迎える準備ができていません（モジュール4でランブックに入れます）。

And beware the catch-up storm. We suppressed downstream synchronization while loading RouteDesk’s records; now we switch the integration back on. Does it see five million “new” records and try to send them all? Maybe the downstream system already received them another way, maybe only changes after the cutover watermark should go, maybe it needs a controlled initial sync. The automation decision and the integration decision have to work together. Turning automation back on isn’t enough: know what it will do when it wakes up. For Steve Trucking, the status flows and the Change Data Capture subscriber should see only the changes made after cutover, never the weekend’s load. ⟲

AIはバイパスの設計をより重要にする

今度は、新しいケース、変わった取引先、発行されたイベント、キューのタスクに反応するエージェントを加えましょう。移行は機械の規模でデータのパターンを生みます。移行したすべてのレコードにエージェントを反応させたいでしょうか？　偶然そうなってほしくはないはずです。エージェントが引き起こすプロセスは、フロー、トリガー、通知、統合、イベントと同じ一覧に入れ、移行の文脈でそれを抑えるべきなら、意図して設計しましょう。

試験の先へ：AIが変えること。 エージェントは別の種類の副作用で、移行したデータに自律的に反応するかもしれません。エージェントが引き起こす操作もほかの自動化と同じように扱いましょう。動かす、模擬する、延期する、抑えるのどれにするかを決め、その判断をリハーサルでテストします。

ここでアーキテクトが決めること

• 移行するデータの種類ごとに、どの自動化を動かし、不要にし、模擬し、延期するか。一つを止めればそのビジネスロジックを引き受けることになると承知のうえで。
• どの入力規則が永続するデータの真実を表し、どれが移行に特有の扱いを要する現行プロセスのルールか。
• How scoped bypasses are designed into every automation from the start, tested on and off, and deployed long before they’re needed, without an unrestricted “skip everything” path. ⟲
• 派生データ、共有の再計算、遅いプラットフォームのロジックをどう扱うか：ロードのあとに、延期して、あるいはステージングオブジェクトを通じて。
• どの外部への副作用と統合を抑え、あるいは意図して追いつかせるか。そしてリハーサルと切り替えが、通常の自動化が安全に戻ったことをどう証明するか。

判断にする

移行が成功するのは、すべてのフローが動き、すべてのトリガーが発火し、すべての入力規則が実行されたからではありません。それは通常のトランザクションの振る舞いで、移行には別の仕事があります。データを新しいアーキテクチャに移し、重要な真実を守り、必要な派生値を作り、偽の副作用を避け、システムを管理下に置き、それから通常に戻すこと。自動化のそれぞれについて：不要にする、模擬する、延期する、あるいは意図して動かす。でも判断にしましょう。500万件のレコードに判断させてはいけません。

さらに学ぶ

• Salesforce Help, Defer Sharing Calculations （新しいタブで開きます） and ワークフロールール & プロセスビルダーのサポートの廃止 （新しいタブで開きます）, checked 2026-11-01. ⟲
• Salesforce Help, Define Custom Settings （新しいタブで開きます）, Global Variables Resource （新しいタブで開きます） (Flow) and 「数式」、「ワークフロールール」、または「入力規則」の中で「権限セット」を参照する （新しいタブで開きます）; Apex Reference Guide, FeatureManagement Class （新しいタブで開きます）, Custom Settings Methods （新しいタブで開きます） and Custom Metadata Type Methods （新しいタブで開きます）, Winter ‘27; all checked 2026-11-01. ⟲
• Salesforce Architects, decision guide, Record-Triggered Automation （新しいタブで開きます） (“Bypassing Automation”), checked 2026-11-01. ⟲
• Salesforce Architects, Well-Architected, Automation Patterns （新しいタブで開きます） and Resource and Cost Optimization （新しいタブで開きます）, checked 2026-11-01. ⟲
• Salesforce, Apex Developer Guide, Execution Governors and Limits （新しいタブで開きます）, Winter ‘27 (API version 68.0), and Change Data Capture Developer Guide, Change Data Capture Allocations （新しいタブで開きます）, checked 2026-11-01. ⟲
• このコースの中では：統合とデータの移動（統合のデータ契約）と大規模に向けた設計。