적재 중의 자동화

🌐 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)

Data Architect 과정 10장인 마이그레이션과 동기화의 모듈 3/5. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 대용량 적재 · 다음: 전환 주말

이 모듈이 답하는 질문: 마이그레이션 데이터를 적재하는 동안 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만 통을 보낸 뒤에야 그 답을 발견하고 싶지 않습니다.

세 가지 선택: 필요 없음, 시뮬레이션, 연기

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년 동안 함께한 고객에게 “저희 회사에 오신 것을 환영합니다!”는 필요 없습니다. 계정 하나를 넣으면 이메일이 하나 나가고, 계정 100만 개를 적재하면, 저는 이메일 100만 통이 필요 없습니다.

시뮬레이션. 자동화는 돌면 안 되지만, 그것이 만드는 결과는 여전히 필요합니다. 계정 생성 시 Flow가 고객 세그먼트를 도출합니다. 마이그레이션된 계정에는 유효한 세그먼트가 필요하지만, Flow 전체를 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

제 더 강한 입장은 이것입니다. 중요한 자동화에는 계획된 마이그레이션이 없어도 통제된 우회로가 있어야 합니다. 그것이 필요한 이유가 마이그레이션만은 아닙니다. 대규모 개선, 데이터 수정, 백필, 통합 복구, 긴급 복구. 때로는 정상 자동화의 모든 조각 없이 통제된 작업을 돌려야 합니다. 유일한 방법이 운영 환경에서 Flow를 편집하거나, 트리거를 비활성화하거나, 유효성 검사 규칙을 지우는 것이라면, 우리는 운영 작업을 쓸데없이 위험하게 만든 것입니다. 그리고 운영 환경에서 트리거를 그냥 끌 수는 없습니다. 테스트가 딸린 배포입니다.

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. ⟲

주의해야 할 냄새는 이것입니다. 대상이 값을 요구하는데 원본에는 없으니 “그냥 전부 ‘알 수 없음’으로 채우자.” 알 수 없음이 상태를 정말로 설명하는 승인된 값이라면 괜찮습니다. 유효성 검사를 통과하려고 가짜 값을 넣는다면, 애플리케이션을 만족시키려고 데이터를 망가뜨리는 것입니다. 저는 모르는 것을 아는 척하느니 마이그레이션 예외, 비워 둘 수 있는 이력 필드, 변환 규칙, 레거시 상태 값을 설계하겠습니다.

자동화는 0의 개수를 곱합니다

계정 200만 개를 적재하고, 자동화가 계정마다 작업 2개를 만듭니다. 작업 400만 개입니다. 의도한 것인가요, 사고인가요? 그다음 각 작업이 또 다른 Flow를 실행하고, 계정 자동화가 부모를 갱신하고, 이벤트를 게시하고, 다른 무언가를 재계산합니다. 마이그레이션 성능은 Bulk API가 계정을 얼마나 빨리 삽입하느냐가 아닙니다. 진짜 워크로드는 그 삽입이 만드는 트랜잭션 그래프입니다. 0의 개수는 자동화를 통해 곱해집니다.

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

이제 결정이 보입니다. 검토하고, 테스트하고, 리허설하고, 적재 후에 검증할 수 있습니다.

우회를 리허설하고, 다시 켜십시오

운영 환경을 마이그레이션 모드의 첫 사용처로 만들지 마십시오. 리허설에서는 마이그레이션 정체성, 우회 통제, 켜져 있는 자동화, 시뮬레이션된 결과, 연기된 프로세스, 정상 모드로의 복귀를 테스트한 다음 확인해야 합니다. 일어나지 말아야 할 것이 실행되었나요, 일어나야 할 것이 일어나지 않았나요, 최종 상태가 아키텍처와 맞나요? 그래서 리허설에는 실제 자동화 구성이나, 가능한 한 그에 가까운 구성이 필요합니다.

다시 켜는 것은 전환 단계입니다. 명시적이고, 이름이 붙은 책임자와 예상 시간과 검증이 있습니다. “Flow 다시 켜는 거 잊지 마세요”가 아닙니다. 정상 운영이 복구되고 검증될 때까지 시스템은 사용자를 맞을 준비가 된 것이 아닙니다(모듈 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는 우회 설계를 더 중요하게 만듭니다

이제 새 케이스, 바뀐 계정, 게시된 이벤트, 큐에 있는 작업에 반응하는 에이전트를 더해 보십시오. 마이그레이션은 기계 규모의 데이터 패턴을 만듭니다. 마이그레이션된 레코드 하나하나에 에이전트가 반응하기를 원하나요? 우연히 그렇게 되기를 원하지는 않을 겁니다. 에이전트가 일으키는 프로세스는 Flow, 트리거, 알림, 통합, 이벤트와 같은 목록에 들어가야 하고, 마이그레이션 맥락에서 그것을 억제해야 한다면 의도적으로 설계하십시오.

시험 너머: 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. ⟲
• 파생 데이터, 공유 재계산, 느린 플랫폼 로직을 어떻게 다루는지: 적재 후, 연기, 또는 스테이징 객체를 통해.
• 어떤 외부 부작용과 통합을 억제하거나 의도적으로 따라잡게 하는지, 그리고 리허설과 전환이 정상 자동화가 안전하게 복구되었음을 어떻게 증명하는지.

결정으로 만드십시오

모든 Flow가 돌고, 모든 트리거가 실행되고, 모든 유효성 검사 규칙이 평가되었다고 마이그레이션이 성공한 것은 아닙니다. 그것은 정상적인 트랜잭션 동작이고, 마이그레이션의 일은 다릅니다. 데이터를 새 아키텍처로 옮기고, 중요한 진실을 지키고, 필요한 파생 값을 만들고, 거짓 부작용을 피하고, 시스템을 통제 가능하게 유지하고, 그다음 정상으로 돌려놓는 것. 자동화마다: 필요 없음, 시뮬레이션, 연기, 또는 의도적으로 실행. 하지만 결정으로 만드십시오. 레코드 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. ⟲
• 이 과정에서: 통합과 데이터 이동(통합 데이터 계약), 규모를 위한 설계.