Salesforce Platform은 복잡한 비즈니스 프로세스의 요구를 충족하기 위해 자동화 아키텍처를 지속적으로 향상했습니다. 이전 세대(워크플로 규칙 및 프로세스 빌더)는 이벤트 중심 논리의 초기 단계를 제공하여 이벤트 중심 논리의 자동화 기능을 확장하고 더 광범위한 빌더에게 도달 범위를 확대했습니다.

이러한 발전은 다음의 두 가지 보완적인 기둥에 중점을 둔 고성능 통합 아키텍처로 끝났습니다. 레코드 트리거 플로 및 Apex 트리거. 이 문서에서는 트리거 자동화를 설계할 때 정보에 근거한 결정을 내릴 수 있는 프레임워크 및 지침을 제공합니다.

Salesforce Platform에서 확장 가능, 유지 가능, 성능이 뛰어난 레코드 트리거형 자동화를 구축하려면 아키텍처를 기반으로 한 규제에 따른 접근 방식이 필요합니다. Flow와 Apex 사이의 선택과 각각의 구현은 명확한 원칙 집합에 따라 결정됩니다. 이러한 사항은 이러한 원칙을 요약하고 현대 자동화 설계의 기본 규칙 역할을 합니다.

• Salesforce 개체 자동화 밀도에 따라 작업에 적합한 도구를 선택합니다.

  • Salesforce 개체에 대한 레코드 트리거형 플로를 사용하여 저밀도 자동화를 수행합니다.

  • 호출 가능한 Apex를 사용하여 레코드 트리거형 플로 논리를 증가하여 중간 밀도 자동화

  • Salesforce 개체에 대한 Apex 트리거를 사용하여 고밀도 자동화를 수행합니다.

• 비동기 프로세스를 트리거할 때 주의하십시오.
  이 규칙은 레코드 트리거 플로에서 비동기 프로세스를 호출하거나 Apex 대기 가능한 작업을 대기열에 지정하는 경우에 적용됩니다. 이 패턴은 작업을 오프로드하는 데 유혹할 수 있지만 복잡한 오류 처리 시나리오를 도입하고 총괄자 제한에 도달할 위험을 높일 수 있습니다.

• Salesforce 개체당 하나의 입력 지점을 사용합니다.
  지정된 Salesforce 개체의 경우 한 메커니즘을 자동화의 진입점으로 사용합니다. 동일한 개체에 대한 입력 지점으로 Flow 및 Apex 트리거를 혼합하지 마십시오.

플로와 Apex 일반적인 기본 기능 집합을 공유합니다. 각 도구는 레코드를 쿼리하고, 조건부 논리를 실행하고, 변수를 할당하고, 지정된 순서대로 실행되도록 순서가 지정된 레코드 만들기, 업데이트, 삭제와 같은 DML 작업을 수행할 수 있습니다.

그러나 이 기능적 겹침은 도구를 상호 교환할 수 있다는 의미는 아닙니다. 아키텍처 선택은 과업을 수행할 수 있는지 여부가 아니라 과업을 수행하는 방법 및 성능, 확장성, 유지 관리에 미치는 장기적인 영향에 관한 것입니다. 플로는 선언적 명확성과 간단한 프로세스를 구현하는 속도에서 우수하며, Apex 복잡한 솔루션에 필요한 세부적인 제어 및 원시 기능을 제공합니다.

자동화 밀도은 특정 Salesforce 개체에 배치되는 로드입니다. 이는 개체의 최적 구현을 결정하기 위한 heuristic 역할을 합니다. 자동화 밀도가 증가함에 따라 트랜잭션 제한을 위반할 가능성이 증가합니다.

볼륨 및 복잡성의 세 가지 특정 치수를 검사하여 자동화 밀도를 계산합니다.

• 자동화 수량: 단일 DML(데이터 조작 언어) 이벤트 동안 실행되는 고유한 자동화 메타데이터 항목(플로, 트리거 작업 등)의 원시 수입니다.

• 레코드 볼륨: API 로드 또는 대량 배치 처리를 통해 처리되는 트랜잭션당 레코드이며, 이는 성능이 매우 중요합니다.

• 독립성 확산: 초기 CRUD 작업으로 트리거된 다운스트림 DML 작업의 측정값입니다. 관련 개체에 대한 하나의 업데이트가 계단식으로 업데이트되는 그래프의 깊이를 수량화합니다(예: 사례 → 계정 → 연락처 → 사용자 정의 롤업).

Salesforce 응용 프로그램의 범위와 복잡성이 증가함에 따라 레코드 트리거형 플로 또는 Apex 트리거와 같은 단일 기본 엔트리포인트를 사용하십시오. 단일 Salesforce 개체에서 여러 메커니즘 전반에 걸쳐 자동화를 분할하지 마십시오. 이는 서비스 점검이 불가능하고 관리가 분할되지 않게 만듭니다.

이 매트릭스를 사용하여 Salesforce 개체에 대한 필수 아키텍처 표준을 결정합니다.

• 레코드 트리거 플로는 낮은 자동화 밀도에 대한 선호 솔루션입니다. 간단하고 서로 독립적인 자동화에 이상적인 기능과 접근성의 균형을 제공합니다.

• **하이브리드 패턴(Record-Triggered Flow with Invocable Apex)**은 복잡성이 증가하는 중간 집적도 자동화에 강력하고 유지 보수 가능한 선택입니다. 이 패턴을 사용하면 팀이 계산량 작업을 Apex 위임하면서 선언적 플로에서 순서가 지정된 큐레이그래픽을 유지할 수 있어 액세스 가능성과 성능의 균형을 유지할 수 있습니다.

• Apex 트리거는 고집적 자동화를 지원하는 견고한 아키텍처 기반을 위한 필수 빌딩 블록을 제공합니다. Apex 성능, 세분화된 제어, 개체 지향적 추상화 및 다형성은 이러한 시나리오의 복잡성과 규모를 관리하는 데 더 적합합니다.

또한 Salesforce는 멀티테넌트 환경에서 공유 자원 관리 및 관리자 제한을 적용하여 런웨이 자동화가 공유 자원을 독점하지 않도록 하기 때문에 일일 총 DML 작업 수를 고려하십시오. 일일 DML 용량이 많은 Salesforce 개체는 주의를 기울여 자동화를 선택해야 합니다. 예를 들어, CPU 시간(60,000ms) 및 힙 크기(12MB)에 대한 비동기 제한은 동기 제한보다 높습니다. 또한 비동기 실행에 대한 조직 전체 24시간 제한(사용자 라이센스의 250,000배 또는 200배)은 런타임 예외를 피하기 위해 아키텍처 설계에 일일 총 DML을 고려해야 합니다.

레코드 트리거형 플로는 레코드 트리거형 자동화를 위한 플랫폼의 주요 선언적 도구입니다. 플로의 사용 편의성과 내장된 플랫폼 보안을 통해 팀은 확장 가능하고 신뢰할 수 있는 솔루션을 쉽게 구축할 수 있습니다. Salesforce Platform에 솔루션을 구축하는 대부분의 팀에게 이상적인 선택입니다.

Apex 플랫폼의 독점적이고 강력하게 입력된 개체 지향 프로그래밍 언어입니다. 자동화 밀도가 높은 Salesforce 개체 및 고성능, 정교한 논리 또는 트랜잭션을 세부적으로 제어해야 하는 사용 사례에 Apex 사용합니다.

결정 프로세스를 지원하기 위해 이 매트릭스는 핵심 아키텍처 기능 전반에서 플로 및 Apex 직접 비교합니다.

이 표는 제시된 기능을 기반으로 일반적인 사용 사례에 대한 일반적인 "최적화" 권장 사항을 제공합니다. 궁극적으로 이 문서의 관련 모범 사례 섹션에 포함된 경우와 같이 특정 시나리오에 가장 적합한 시나리오를 찾으려면 추가 고려 사항을 고려해야 합니다. 여기에서 플로 및 Apex 특정 조합이 가장 적합한 접근 방식을 제공하는 경우에 대해 자세히 알아볼 수 있습니다.

확장성은 구현을 설계할 때 중요한 고려 사항입니다. 레코드 트리거형 자동화의 비즈니스 논리가 복잡하거나 장기적으로 실행되거나 데이터 용량이 많은 경우 Salesforce Platform의 핵심 총괄자 제한이 아키텍처 제약이 됩니다. 대량 데이터 업데이트, 복잡한 API 콜아웃 또는 대량 계산과 같은 작업은 단일 데이터베이스 트랜잭션 내의 총 CPU 시간 또는 DML 문 수와 같은 제한을 위반할 위험을 높입니다. 제한 예외로 인해 동기 트리거에 실패하면 사용자의 전체 저장 트랜잭션이 롤백되므로 사용자 환경이 좋지 않고 잠재적인 데이터 손실이 발생합니다. 이 기본적인 위험은 복잡한 작업을 오프로드하기 위한 아키텍처 패턴을 요구합니다.

이 경우 비동기 자동화가 필수 항목이 됩니다. 아키텍처는 비동기 메커니즘을 사용하여 장기 실행 또는 대용량 작업을 기본 동기식 레코드 저장 트랜잭션에서 효과적으로 분리할 수 있습니다. 많은 처리가 나중에 실행되는 별도의 플랫폼 관리 트랜잭션에 위임되는 동안 신속하고 신뢰할 수 있게 완료합니다. 분리하면 안정성이 향상되고 트랜잭션 실패를 방지하며 확장 가능한 엔터프라이즈 응용 프로그램을 구축하는 데 매우 중요합니다. 플랫폼은 신뢰성, 볼륨, 복잡성과 관련하여 각각 고유한 혜택과 제약을 제공하는 몇 가지 특수한 도구를 제공합니다.

레코드 트리거형 플로에서 비동기식으로 실행 경로는 비동기식 논리에 대한 가장 간단한 메커니즘을 제공합니다. 이 경로는 원래 레코드 저장 트랜잭션이 데이터베이스에 성공적으로 커밋된 후 별도의 트랜잭션으로 실행됩니다.

• ** 이상적인 사용 사례**: 즉시 실행하거나 사용자 정의 오류 처리가 필요하지 않은 과업에 적합합니다. 예를 들어 이메일 알림 보내기, 팔로우업 과업 만들기 또는 외부 시스템에 대한 간단한 콜아웃을 수행할 수 있습니다.

• 제한 사항: 이 메커니즘은 다른 비동기 플로 인터뷰와 동일한 일일 총괄자 제한을 공유합니다. 매우 대용량 처리에 고안되지 않았습니다.

변경 데이터 수집(CDC)은 대용량 시나리오에서 레코드 변경으로 인해 트리거되는 비동기 논리를 처리할 수 있는 대용량, 확장 가능 및 복원형 패턴입니다. 이 모델에서 트리거의 유일한 책임은 레코드를 동기식으로 저장하는 것입니다. 그러면 플랫폼이 대용량 이벤트 버스에 레코드의 변경 사항을 포함하는 자세한 이벤트 메시지를 게시합니다. 별도의 전용 Apex 트리거가 이 변경 이벤트를 구독합니다. 복잡한 장기 실행 또는 비동기 작업을 수행합니다.

• 혜택: 이 패턴은 초기 사용자 트랜잭션에서 비동기 프로세스를 분리합니다. 비동기식 처리에 실패하면 사용자의 레코드 저장이 롤백되지 않습니다. 또한 패턴은 여러 내부 구독자 또는 외부 시스템에서 사용할 수 있는 지속적인 이벤트 스트림을 제공하며 최대 72시간 동안 이벤트를 재생할 수 있어 강력한 복원 능력을 제공합니다.

• 제한 사항: CDC 이벤트 메시지에는 Apex Trigger.oldMap에 상응하는 레코드의 이전 상태가 포함되어 있지 않습니다. 이벤트 페이로드에는 변경된 값이 아닌 새 필드 값이 포함됩니다. 따라서 특정 상태 전환을 기반으로 논리를 구현하는 것이 어려워집니다(예: Status__c가 "보류 중"에서 "승인됨"으로 변경된 경우에만 실행). 이벤트 구독자에서 개체의 필드 내역을 쿼리하여 이를 완화할 수 있지만, 이를 통해 프로세스에 복잡성이 추가되고 특정 관심 필드에 필드 내역 추적을 사용할 수 없습니다. 따라서 CDC에 오프로드할 수 있는 자동화 유형을 제한할 수 있습니다.

기본적으로 최대 5개의 Salesforce 개체에 대해 CDC를 활성화할 수 있습니다. 필요한 조직은 이 제한을 제거하고 이벤트 배달 할당을 늘리는 추가 기능 라이센스를 구매할 수 있습니다.

트리거에서 직접 대기 가능한 Apex 작업을 대기열에 지정하는 것은 위험한 패턴으로 간주되어야 하며, Apex 제공 제어가 필요한 경우에만 사용됩니다(예: 복잡한 논리 또는 사용자 정의 재시도 메커니즘). CDC는 실행 가능한 옵션이 아닙니다.

대기 가능한 Apex 필요한 경우 구현에 적절한 보안 조치가 포함되어야 합니다.

• 제한 점검: 다른 작업을 추가하려면 먼저 코드가 트랜잭션에 이미 대기열에 있는 작업 수를 확인해야 합니다.

• 컨텍스트 인식: 코드는 일괄 처리 작업(System.isBatch())과 같은 비동기 컨텍스트 내에서 실행되는지 여부를 감지하고 해당 컨텍스트에서 더 엄격한 일괄 처리/트랜잭션 한도에 따라 동작을 수정해야 합니다.

동기식 트리거에서 비동기식 Apex 호출하면 안정성 위험이 발생합니다. 조직 수준 영향(예: 제한 초과)을 방지하려면 이 패턴을 엄격하게 설계하고 테스트해야 합니다.

• 비동기식 Apex 실행(Batch, Queueable, @Future)의 일일 제한은 조직 전체에서 공유됩니다(일반적으로 250,000개 또는 사용자 라이센스를 기반으로 계산). 레코드의 대량 데이터 로드가 20,000개인 경우 트리거가 200개의 청크로 실행되므로 대량 배치 크기가 200개 미만인 경우 100개의 별도의 트리거 호출이 발생합니다. 각 호출이 비동기 작업을 대기열에 지정하는 경우 단일 데이터 로드에서 일일 제한의 상당 부분이 사용될 수 있습니다. 이러한 소비는 비동기 자원의 기타 중요한 비즈니스 프로세스를 잠재적으로 해체할 수 있습니다.

• 대기열 작업에 대한 총괄자 제한은 컨텍스트에 따라 크게 다릅니다. UI에서 사용자 작업에 의해 실행되는 트리거(동기식 트랜잭션)에서 최대 50개의 대기 가능한 작업을 대기열에 지정할 수 있습니다. 그러나 배치 Apex 클래스의 execute 방법(비동기 트랜잭션) 내에서 시작된 트리거에서 하나의 대기 가능 작업만 대기열에 지정할 수 있습니다. 이 차이를 고려하지 못하는 것은 일반적이고 중요한 오류 지점이며, 대용량 데이터 작업 중에 LimitException 오류가 발생합니다.

• 트리거 컨텍스트에서 직접 Schedulable Apex(System.schedule) 또는 Batch Apex(Database.executeBatch)를 호출하는 것은 안티 패턴입니다. 이러한 메서드는 트리거 컨텍스트에서 호출되도록 설계되지 않았습니다. 이렇게 하면 비동기식 Apex 할당이 신속하게 소비되므로 한도 예외가 발생합니다.

각 비동기 메커니즘에는 성능, 총괄자 제한, 신뢰성과 관련된 특정 제약이 있습니다. 이 결정 트리를 가이드로 사용하여 이러한 옵션을 탐색하고 사용 사례에 적합한 메커니즘을 선택할 수 있습니다.

플로 차트에 표시된 바와 같이 대용량 DML 작업이 있지만 변경 데이터 수집 사용할 수 없는 경우(개체 제한으로 인해 발생할 수 있음) 트리거 호출 프로세스를 완전히 피하는 것이 아키텍처에 가장 적합한 선택입니다.

대신 예약된 프로세스를 사용하는 것이 좋습니다. 이는 예약 플로 또는 예약된 Apex 수 있습니다. 필수 단계는 다음과 같습니다.

1. 동기식 트리거에서 간단하고 비용이 적은 간단한 업데이트를 수행합니다. 예를 들어, Status__c 필드를 "처리 대기 중"으로 설정하거나 Chatter 게시와 같은 저가 관련 레코드를 삽입하여 레코드가 처리되어야 함을 나타냅니다.

2. 15분 또는 매시간과 같이 정기적으로 실행되는 예약된 작업(예: 예약된 플로 또는 예약된 Apex)을 만듭니다.

3. 보류 중 상태인 모든 레코드에 대해 예약된 작업 쿼리를 만들어 제어되는 대용량 컨텍스트에서 복잡한 논리를 실행한 다음, 처리된 레코드를 업데이트합니다.

이 패턴은 사용자의 동기 저장에서 대량 처리를 완전히 분리하고 트리거 시작 배치의 트랜잭션당 하나의 작업 제한에 적용되지 않으며 비실시간 요구 사항에 대해 확장 가능하고 관리 가능한 솔루션을 제공합니다.

예약된 작업의 대기 시간이 비즈니스 요구 사항에 허용되지 않으며 계속해서 CDC 또는 트리거 실행 대기 가능한 대기열을 사용하지 않아도 되는 경우 이는 중대한 아키텍처 불일치가 있음을 나타냅니다. 이때 다른 메커니즘을 고려해야 합니다. 핵심 응용 프로그램 설계를 다시 평가하면 다음과 같은 특정 결론을 내릴 수 있습니다.

• 추가 기능을 구매하여 CDC 개체 제한을 제거합니다.

• 근 실시간 처리가 실제로 "필수"인지 아니면 예약된 작업의 대기 시간이 플랫폼 안정성에 허용되는 제약인지를 결정하기 위한 비즈니스 요구 사항을 근본적으로 도전합니다.

구현의 복잡성 수준은 솔루션의 총 소유 비용과 변화하는 비즈니스 요구 사항에 적응할 수 있는 기능의 일부입니다. 모범 사례를 따르지 않으면 복잡성이 구현에 영향을 미칠 수 있습니다. 이 문서의 관련 모범 사례 섹션에는 다음 패턴을 포함하여 솔루션의 복잡성을 줄이기 위한 권장 사항이 있습니다.

• 하이브리드 패턴: 플로의 복잡한 논리를 위한 호출 가능한 Apex

• Apex 트리거에 대한 메타데이터 프레임워크 사용

• 메가 플로와 비교. 다중 플로

문서는 자동화 자체만큼이나 중요합니다. 유지 관리 기능을 제공할 뿐만 아니라 AI 및 에이전트 기반 도구에도 중요합니다. 문서는 비즈니스 프로세스를 이해하고 관리하는 데 도움이 됩니다.

In Flow

• 모든 요소 및 변수에 일관된 명명 규칙을 설정합니다.

• 플로에 대한 설명 필드를 사용하여 전체적인 목적, 트리거 기준, 의도한 결과를 설명합니다.

• 각 개별 요소에 대한 설명 필드를 사용합니다(예: Get Records, Action, Transform). 이 방법은 의도를 전달하는 가장 좋은 방법입니다. 특히 설명이 작업에서 수행하는 복잡한 논리를 설명하는 기본 위치인 호출 가능한 작업 및 하위 플로에 중요합니다.

In Apex

• 코드를 명확하게 코멘트하여 논리의 왜, _어떤 것_뿐 아니라 설명합니다.

• 메타데이터 구동 프레임워크를 사용하는 경우 메타데이터 레코드에 사람이 읽을 수 있는 설명 필드가 포함되어 있어 각 처리기 클래스가 수행하는 작업과 실행 시점을 설명합니다.

DevOps 및 소스 제어는 성숙한 개발 수명 주기의 일부입니다. 항상 Salesforce 프로젝트용 Git와 같은 소스 제어 도구를 사용하십시오. Apex 클래스와 Salesforce 플로는 모두 비즈니스 논리를 정의하는 메타데이터이며 버전을 지정하고 관리해야 합니다.

레코드 트리거형 자동화 관리의 컨텍스트 내에서 최신 DevOps 파이프라인은 필수적인 이점을 제공합니다.

• 자동 품질 점검: Salesforce Code Analyzer과 같은 도구를 파이프라인에서 자동으로 실행하도록 구성할 수 있습니다. 정적 분석은 두 자동화 도구에서 문제가 발생하기 전에 문제 패턴을 감지할 수 있으며, 이는 성능 저하의 일반적인 원인인인 Flow 루프 내의 비효율적인 Get Records 요소 또는 Apex for 루프 내의 SOQL 쿼리와 같은 문제를 표시합니다.

• 복귀 예방: 자동화 밀도가 증가함에 따라 하나의 Flow 또는 Apex 클래스로 변경하면 동일한 객체의 다른 자동화에 의도하지 않은 결과가 발생할 수 있습니다. 제안된 변경 사항에 대해 자동화된 Apex 테스트를 실행하는 강력한 DevOps 테스트 전략은 새로운 Flow 버전이 기존 Apex 논리를 중단하지 않도록 보장하는 가장 신뢰할 수 있는 방법입니다(그 반대로).

• 공동 작업 및 가시성: 소스 제어는 "단일 신뢰할 수 있는 소스"입니다. 관리자와 개발자가 동일한 개체에 대한 자동화 작업을 병렬로 수행할 수 있습니다. 또한 프로덕션 프로세스가 중단되면 자동화를 변경한 사람, 변경한 시기, 커밋 메시지를 통해 변경한 이유를 즉시 확인할 수 있습니다.

관리자와 개발자가 혼합된 팀의 경우, DevOps Center는 통합 인터페이스를 제공하여 이러한 모든 단계를 구성할 수 있도록 도와주므로 팀의 모든 구성원이 확장 가능한 소스 제어 기반 개발 프로세스를 이용할 수 있습니다.

문서 및 DevOps를 결합한 이 분야는 조직의 장기적인 상태 및 유지 관리 기능을 보장하므로 사용자를 팔로우하는 모든 설계자와 관리자에게 도움이 됩니다.

위의 결정 가이드는 구현을 계획하기 전에 가장 적합합니다. 사용 사례에 가장 적합한 제품을 선택할 수 있도록 지원합니다. 제품을 선택한 후 구현을 위한 기존 모범 사례를 이해하는 것이 중요합니다.

One Tool Per Object 원칙은 고밀도 자동화 관리에 매우 중요하지만, 단순히 선언적 또는 단순히 프로그래밍 방식의 스택 사이의 이진 선택으로 해석하지 마십시오. 보다 효과적이고 유지 보수 가능한 아키텍처 패턴은 하이브리드 모델을 활용합니다. Record-Triggered Flow 를 오케스트레이션 계층으로 배치하고 고복잡성 작업을 Invocable Apex 내에 캡슐화합니다.

레코드 트리거 플로는 비즈니스 프로세스의 오케스트레이션 계층 역할을 합니다. 그것은 입장 기준과 실행 컨텍스트 (_무슨_과 언제)를 소유합니다. 결정 논리와 라우팅을 이 계층 내에 유지함으로써 플로 트리거 탐색기를 통해 아키텍처의 프로세스 토폴로지를 투명하고 관리할 수 있어 중요 비즈니스 논리가 코드 내에서 숨겨지지 않도록 방지합니다.

복잡한 구성 요소의 일반적인 예는 사례 레코드에 대한 서비스 수준 계약(SLA) 계산 구현입니다. 비업무 시간 및 휴일을 제외한 정확한 계산에 중요한 BusinessHours 개체와 관련 논리가 Flow에서 기본적으로 액세스할 수 없으므로 전용 Apex 클래스가 사용됩니다. 이 클래스는 종종 ServiceLevelAgreementCalculator과 같은 이름을 지정하며, @InvocableMethod로 주석이 지정된 단일 정적 방법으로 설계되어 경과된 업무 시간을 계산하고 SLA가 "목표 범위 내" 또는 "실패"인지 확인하고 구조화된 출력을 반환합니다. 이 접근 방식은 복잡한 고성능 논리를 Apex 캡슐화하면서 레코드 트리거 플로의 선언적 오케스트레이션 계층에 원활하게 실행하고 통합할 수 있도록 합니다.

Apex ServiceLevelAgreementCalculator 클래스가 정의되면 레코드 트리거 플로 내에서 사용할 수 있습니다.

이 패턴은 우려 사항을 엄격하게 구분하는 것을 보여줍니다. 선언적 레이어는 트랜잭션 수명 주기 및 오케스트레이션을 관리하는 데 사용되며 코드는 복잡한 실행에 사용됩니다. 코드를 기초가 아닌 기능 유틸리티로 취급하여 성능과 서비스 점검의 균형을 맞춥니다.

모듈러성: 이 결정은 전체 프로세스에 Apex 또는 Flow를 사용하는 독특성에서 벗어납니다. 대신 아키텍처는 복잡한 논리를 추가된 대량 안전한 독립적으로 테스트 가능한 단위로 캡슐화합니다. 이러한 단위는 선언적 레이어에서 사용되는 재사용 가능한 구성 요소로 작동하므로 아키텍처 설계가 복잡하지 않고 자동화의 규모를 확장할 수 있습니다.

재사용 가능: 논리가 트리거 이벤트에서 분리됩니다. 잘 설계된 코드 유닛(예: InvocableMethod)은 한 번 작성되지만 여러 입력 지점에서 활용됩니다. 레코드 트리거 플로, 화면 플로 또는 외부 통합 이 코드를 재사용하면 중복 개발이 제거됩니다.

기존성: 프로세스 플로 논리는 선언적 플로 내에서 계속 표시되고 관리할 수 있습니다. 이 중앙 집중화를 통해 디버깅 오버헤드가 크게 줄어들고 시스템의 실행 순서가 결정적이고 투명해집니다.

플로에서 호출 가능한 Apex 사용하는 하이브리드 모델은 강력하지만, 일대일 접근 방식은 아닙니다. 설계자는 하이브리드 솔루션을 적용하기 전에 특정 제한 사항 및 제약 사항을 알고 있어야 합니다.

• 저장 전 지원 안 함: 이는 가장 중요한 제한입니다. 호출 가능한 작업은 저장 후 컨텍스트(작업 및 관련 레코드의 플로)에서만 사용할 수 있습니다. 고성능 저장 전 컨텍스트(빠른 필드 업데이트를 위한 플로)에서는 사용할 수 없습니다. 따라서 이 패턴을 사용하여 동일한 레코드 필드 업데이트를 위임할 수 없습니다. 저장 전 플로 또는 컨텍스트 전 Apex 트리거 내에서 기본 Flow 요소를 사용하여 고성능 작업을 수행합니다.

• 삭제 취소 후 지원 없음: 레코드 트리거형 플로는 현재 삭제 취소 후 컨텍스트를 지원하지 않습니다. Salesforce 개체에 휴지통에서 레코드를 복원할 때 자동화를 실행하는 비즈니스 요구 사항이 있는 경우 Apex 트리거가 유일한 해결 방법입니다.

• 고용량 시나리오의 성능 오버헤드: 플로 런타임에서 Apex 런타임으로의 전환은 비용이 없는 작업이 아닙니다. 일반적으로 빠르지만, Flow 런타임에서 호출 가능한 작업으로 끌어오는 작업은 Apex 트리거 내에 있는 네이티브 실행만큼 빠르지 않습니다. 대부분의 중간 밀도 자동화의 경우 이 마이크로 오버헤드는 액세스 가능성 향상을 위해 소소하고 가치 있는 제약입니다. 그러나 극도로 고성능, 대용량 시나리오의 경우 순수한 Apex 전용 프레임워크는 원시 컴퓨팅 속도 이점이 있습니다.

자동화 밀도 heuristics는 최신 그린필드 아키텍처에 대한 확실한 지침을 제공하지만, 엔터프라이즈 Salesforce 환경의 현실은 종종 더 구체적입니다. 성숙한 조직에서는 동일한 Salesforce 개체에서 작동하는 레코드 트리거 플로 및 Apex 트리거를 찾는 것이 일반적입니다. 이 시나리오는 앞서 설명한 하이브리드 패턴과는 다릅니다. 여기서, 플로와 Apex 트리거는 결합되거나 함께 작동하도록 설계되지 않습니다.

이러한 공존은 플랫폼 기능이 발전하거나 기존 기술 부채로 인해 발생하는 경우가 많습니다. 이 상태는 허용되는 운영 상태이지만, 설계자는 최종 상태가 아닌 계산된 제약으로 취급해야 합니다.

조각화된 오케스트레이션은 상당한 거버넌스 및 유지 보수 오버헤드를 야기하므로 개발, 테스트, 사고 처리 활동이 분리되고 번거롭습니다. 이를 통해 해결 시간(TTR) 및 운영 복잡성이 증가됩니다.

• 새 Salesforce 개체의 경우 자동화 밀도 원칙을 기본 가이드로 준수하십시오.

• 하이브리드 이력과 이중 Apex 트리거와 레코드 트리거형 플로 입력 지점이 있는 기존 Salesforce 개체의 경우 밀도를 평가한 다음, 재구성기를 유지 관리 가능한 하이브리드 상태로 구성합니다.

  • 밀도가 낮으면 리팩터 Apex 레코드 트리거 플로를 트리거하고 실행 순서를 지정하여 단일 자동화 입력 지점으로 이동합니다.

  • 중간 밀도의 경우 리팩터 복합이 올바른 실행 순서로 플로의 하위 집합으로 메가 플로를 수행합니다. 절대적으로 필요한 경우에만 Apex 트리거를 도입합니다(예: 컨텍스트 삭제 취소 후 지원).

  • 높은 밀도의 경우 Apex 트리거를 구현하는 것이 좋습니다.

Salesforce Platform에서 조직의 비즈니스 프로세스가 성숙해지면 레코드 트리거형 자동화의 용량과 복잡성이 불가피하게 증가합니다. 기본적인 모범 사례는 Salesforce 개체당 _한 개의 Apex 트리거_를 유지하는 것입니다. 플랫폼이 동일한 이벤트에 대해 동일한 개체에서 여러 트리거의 실행 순서를 보장하지 않으므로 이 규칙이 중요합니다. 이 제한은 결정적이지 않은 동작, 인종 조건 및 디버그하기 어려운 문제로 이어질 수 있습니다.

그러나 단일 트리거 원칙을 준수하면 관리 가능하고 확장 가능한 방식으로 단일 엔트리포인트에서 호출되는 모든 비즈니스 논리를 관리하고 오케스트레이션하는 아키텍처적인 도전이 발생합니다.

이 아키텍처의 첫 번째 진화는 Classic 트리거 처리기 패턴이었습니다. 이 접근 방식에서는 단일 Apex 트리거가 모든 논리를 해당 처리기 클래스(예: OpportunityTriggerHandler)에 위임합니다. 이 방법은 트리거 파일에서 논리를 분리하고 개발자가 처리기 클래스의 방법(예: afterInsert()) 내에서 실행 순서를 결정적으로 제어할 수 있도록 합니다.

이 패턴은 개선되었지만 종종 모노리틱 처리기 클래스로 이어집니다. 시간이 지남에 따라 더 많은 비즈니스 요구 사항이 추가되면 클래스가 크고 관리하기 어렵고 격리적으로 테스트하기 어렵게 됩니다. 모든 개별 프로세스의 실행 순서는 단일 메서드 내에서 하드 코딩되므로 클래스가 충돌을 병합할 가능성이 있으므로 대규모 엔터프라이즈 환경에서 거버넌스 및 서비스 점검 오버헤드가 크게 증가합니다.

모듈화 및 오케스트레이션의 핵심 문제를 해결하기 위해 아키텍처는 메타데이터 중심 트리거 프레임워크로 전환합니다. 이는 실행 방법 및 시기에 대한 구성에서 자동화 논리 자체를 분리하는 중요한 아키텍처 단계입니다.

이 프레임워크는 다음 세 가지 주요 이점을 기반으로 구축됩니다.

• 파티셔닝: 단일 처리기 클래스 대신 핵심 비즈니스 논리는 작은 원자식 Apex 클래스(예: RecalculateAccountValues 클래스 또는 NotifySalesLeads 클래스)로 분할되며, 각 클래스는 _단일 책임 원칙_을 준수합니다. 이 모듈성을 통해 논리를 쉽게 테스트, 디버그, 이해할 수 있습니다.

• 주문 및 조작: 실행 순서는 더 이상 Apex 하드 코딩되지 않습니다. 대신 구성 레코드에 의해 선언적으로 정의되며, 일반적으로 사용자 정의 메타데이터 유형(예: TriggerAction__mdt)에 저장됩니다. 이렇게 하면 관리자가 배포 또는 코드 변경이 필요하지 않은 메타데이터 레코드를 수정하여 자동화 작업을 다시 정렬, 추가 또는 제거할 수 있습니다.

• Bypass 기능: 프레임워크는 표준화된 세분화된 우회 기능을 제공합니다. 각 자동화 작업은 메타데이터 레코드를 통해 전역적으로 해제되도록 구성하거나 사용자 정의 권한을 참조하여 특정 관리 사용자에 대해 무시할 수 있습니다.

그런 다음, 개체에 대한 단일 Apex 트리거는 동적 발송자로만 작동합니다. 비즈니스 논리를 포함하지 않지만 중앙 MetadataTriggerHandler 클래스를 인스턴스화합니다. 이 처리기는 사용자 지정 메타데이터 레코드를 쿼리하여 실행 순서를 동적으로 결정하고 지정된 순서대로 올바른 원자 Apex 클래스를 호출합니다. 자동화는 투명하고 관리 가능한 단일 계층 아래 통합됩니다.

강력한 프레임워크에서 Apex 사용하면 중복 작업을 제거하여 트랜잭션 상태를 관리하고 성능을 최적화할 수 있는 기능을 활용할 수 있습니다. 논리가 누적되면 저장 주문 내의 다양한 자동화가 동일한 비용이 많이 드는 작업을 독립적으로 실행하여 유용한 총괄자 제한을 소비하고 DML 작업 시간을 늘리는 것이 일반적입니다.

프레임워크는 두 가지 기본 전략인

• 공유 상태 관리: 단일 Apex 트랜잭션 범위 내에서 정적 속성 및 변수가 캐시 데이터에 활용됩니다. 이렇게 하면 트리거의 다른 레코드 또는 단계에서 자동화 논리를 여러 번 호출하는 경우에도 구성 설정에 대한 SOQL 쿼리와 같은 비용이 많이 드는 작업이 한 번만 실행됩니다. 트랜잭션 제한 소비량이 현저하게 감소합니다.

• 플랫폼 캐시 활용도: 단순한 트랜잭션 내 캐싱을 벗어나려면 플랫폼 캐시를 사용하여 특정 데이터에 대한 전체 데이터베이스를 쿼리하지 않도록 합니다. 이 관리형 메모리 내 캐시는 기본이 아닌 데이터를 검색하고, 코드베이스에서 자주 읽고, 트랜잭션 과정에서 변경할 수 없는 데이터(예: 프로필, 역할, 업무 시간)를 검색하는 데 적합합니다. Cache.CacheBuilder 인터페이스를 사용하면 시스템이 캐시를 먼저 확인하고 데이터가 없는 경우에만 데이터베이스 쿼리를 수행하여 성능과 확장성을 극대화합니다.

자동화가 트랜잭션을 시작하는 레코드의 필드 값만 변경해야 하는 경우 항상 저장 전 업데이트를 사용하십시오. 이는 플로의 빠른 필드 업데이트(저장 전에 실행)와 Apex 트리거의 컨텍스트 전 논리에 모두 적용됩니다(삽입 전, 업데이트 전).

이 패턴은 두 번째 DML 작업 및 반복 저장 주기를 방지하므로 사용되는 도구와 상관없이 성능이 향상됩니다. 변경 사항은 레코드가 데이터베이스에 커밋되기 전에 메모리에 적용되며 원래 트랜잭션의 일부로 저장됩니다. 그렇지 않으면 전체 저장 주문을 다시 실행하고 모든 자동화를 다시 실행하는 두 번째 저장에 대한 오버헤드가 제거됩니다.

제어되지 않는 반복은 트리거의 논리가 DML 업데이트를 수행하여 동일한 트리거가 다시 실행되는 후 업데이트 트리거의 일반적인 함정입니다. 이렇게 하면 결국 총괄자 제한 예외로 종료되는 무한 루프가 생성됩니다. 정적 부울 플래그 또는 처리된 레코드 ID의 컬렉션은 과거에 해당 반복을 방지하기 위해 사용되었지만, 보다 정밀하고 강력한 패턴은 레코드 자체의 새 버전과 이전 버전 간 필드 값을 비교하여 논리를 게이트하는 것입니다.

특정 관심 필드가 실제로 변경된 경우에만 논리를 실행합니다. 이렇게 하면 트리거가 중요 데이터가 변경되지 않은 동일한 트랜잭션 내의 후속 DML 작업에서 논리를 실행하지 못할 수 있습니다.

레코드 트리거 플로에서 레코드가 조건 요구 사항을 충족하도록 업데이트되는 경우에만 플로가 실행되도록 설정하여 제어되지 않는 반복을 방지합니다.

플로에 입력 기준 수식을 사용하도록 선택하는 경우 $Record 전역 변수(새 값을 나타내는)와 $RecordPrior 전역 변수(저장 전의 원래 값을 나타내는)를 비교하여 실행 중 반복을 방지할 수 있습니다. 예를 들어 기회의 금액 필드가 변경된 경우에만 플로가 실행되도록 하려면 항목 기준에서 다음을 사용합니다.

레코드의 새 버전인 Trigger.new의 필드 값을 레코드의 이전 버전인 Trigger.oldMap의 필드 값과 비교하여 원하는 변경 사항이 발생했는지 확인합니다. 이 접근 방식을 통해 자동화가 동일하게 작동하고 필요한 경우에만 실행되므로 시스템의 효율성을 높이고 재해가 발생하는 반복 루프를 방지할 수 있습니다.

올바르게 설계된 Salesforce 조직은 자동화를 우회하기 위해 일관되고 신뢰할 수 있는 메커니즘이 필요합니다. 이는 옵션 기능이 아니라 데이터 무결성을 유지하고 관리 과업을 활성화하기 위한 핵심 운영 요구 사항입니다.

다음과 같은 일부 시나리오에서는 무시 프레임워크가 필요합니다.

• 대용량 데이터를 로드할 때 모든 레코드에 대한 트리거를 실행하면 프로세스가 급격하게 느려지며 제한 예외가 발생하고 잘못된 관련 레코드 및 알림이 생성될 수 있습니다. 무시하면 데이터를 원활하고 효율적으로 삽입할 수 있습니다.

• 통합 사용자는 레코드의 외부 시스템에서 데이터를 동기화해야 할 수 있습니다. 일반적으로 사용자 시작 변경(예: 이메일 보내기, 과업 만들기)에 대해 실행되는 자동화는 변경이 다른 시스템에서 시작되었을 때 바람직하지 않거나 중복될 수 있습니다.

• 관리자 또는 지원 담당자가 레코드에 대한 수정 업데이트를 수행해야 할 수 있습니다. 무시 메커니즘을 사용하면 표준 비즈니스 자동화를 트리거하지 않고 이러한 사항을 변경할 수 있으므로 의도하지 않은 결과가 발생할 수 있습니다.

사용자 정의 권한: 무시 논리를 구현하기 위한 최신 확장 가능한 표준은 사용자 정의 권한입니다. 다음은 다음과 같은 몇 가지 이유로 이전 메서드보다 우수합니다.

• 유연성: 권한 집합을 통해 사용자에게 사용자 정의 권한을 할당할 수 있습니다. 이 방법은 최신 Salesforce 보안 및 액세스 모델과 일치하므로 세분화되고 유연한 할당을 수행할 수 있습니다. 특정 사용자에게 무시 또는 특정 만료 일자/시간이 있는 경우 일시적으로 허용할 수 있습니다.

• 기존성: 사용자 정의 권한을 사용하면 프로필 또는 사용자가 자동화 논리에 하드 코딩되지 않습니다. 사용자의 역할이 변경되거나 새 프로필에 액세스 권한을 무시해야 하는 경우 변경 사항은 배포가 필요한 코드 또는 플로 수정이 아닌 간단한 권한 집합 할당입니다.

• 확장성: 사용자 정의 권한은 복잡한 사용자 기반에서 예외를 관리할 수 있는 확장 가능한 프레임워크를 제공합니다. 권한 집합, 권한 집합 그룹 또는 프로필을 통해 사용자에게 할당할 수 있습니다. 권한 집합 또는 프로필에 대한 연결은 소스 메타데이터에서도 표시됩니다.

구현 패턴: 조직의 모든 레코드 트리거형 자동화에 일관된 우회 패턴을 적용합니다.

레코드 트리거 플로 우회: 플로가 실행되지 않도록 차단하는 것이 가장 효과적인 방법입니다. 플로의 항목 기준에 조건을 추가하면 이 작업을 수행할 수 있습니다.

• 레코드 트리거 플로의 시작 요소에서 조건 요구 사항을 수식이 True로 평가됨으로 설정합니다.

  • 수식 빌더에서 $Permission 전역 변수를 사용하여 사용자 정의 권한에 대한 확인을 통합합니다. 기존 항목 기준과 확인을 결합합니다.

    • 수식 패턴:

  • 이 패턴을 사용하면 사용자에게 지정된 사용자 정의 권한이 할당되지 않은 경우에만 플로가 실행됩니다. 이 확인은 플로 인터뷰가 생성되기 전에 수행되므로 가장 성능이 뛰어난 접근 방식입니다.

Apex 트리거 프레임워크 우회: Apex 메타데이터 구동 트리거 프레임워크에 바로 우회 논리를 통합하여 세부적으로 제어할 수 있습니다.

• TriggerAction__mdt 사용자 정의 메타데이터 유형에는 텍스트 필드(예: BypassPermission__c)가 포함되어야 합니다.

  • MetadataTriggerHandler 클래스에서 동적으로 작업을 실행하기 전에 코드는 이 필드의 값을 읽어야 합니다.

  • 필드가 채워지면 처리기가 FeatureManagement.checkPermission() 메서드를 사용하여 현재 실행 중인 사용자에게 지정된 사용자 정의 권한이 있는지 확인합니다.

  • checkPermission()이 true를 반환하면 처리기가 해당 특정 작업을 건너뛰고 순서대로 다음 작업으로 진행합니다.

  • 이 패턴은 전역 우회전(모든 TriggerAction__mdt 레코드가 동일한 권한을 참조하는 경우)과 세분화된 작업 우회전(다른 레코드가 다른 권한을 참조하는 경우 또는 일부 레코드에 우회전 권한이 전혀 없는 경우)을 모두 허용하기 때문에 강력합니다.

이는 모든 개체 자동화를 하나의 대규모 메가 플로로 통합하는 안티 패턴입니다. 하나의 플로에 통합하고 여러 조건이 적절한 플로로 논리를 분할해도 성능에 큰 영향을 미치지 않습니다. 가장 중요한 성과는 다음과 같습니다.

• 동일한 레코드 필드 업데이트에 저장 전 플로 사용

• 정확한 입력 조건을 작성하여 특정 사용 사례에 영향을 미치지 않는 변경 사항에 대해 플로가 실행되지 않도록 합니다.

플로 트리거 탐색기를 사용하면 개체의 각 플로에 순서 값을 할당하여 순차 실행 순서를 보장할 수 있습니다.