Salesforce Platform에서 양식을 작성하려는 경우 전체 하위 코드에서 프로 코드 연속성까지 다양한 옵션을 사용할 수 있습니다. Low-code는 Lightning 앱 빌더의 동적 양식과 Flow Builder의 화면 플로를 나타냅니다. LWC를 사용하여 화면 플로를 확장하고 OmniStudio를 사용하여 고객 대면 양식을 작성하는 기능은 연속 중간에 있습니다. 프로 코드는 LWC 프레임워크와 계속해서 성장하는 기본 구성 요소 라이브러리를 나타냅니다.

옵션은 훌륭하지만 올바른 옵션 또는 조합을 어떻게 결정합니까? 여기에서 이 가이드가 들어갑니다.

• 테이크아웃 #1: Lightning 페이지의 만들기/편집/보기 레이아웃을 작성할 때 동적 양식을 사용하십시오. 이 가이드의 비교 테이블에서 페이지 레이아웃이 누락되었는지 확인할 수 있습니다. 앞으로 레코드 세부 사항 페이지를 구성하는 것이 좋습니다. Lightning 앱 빌더에서 동적 양식을 사용하는 것이 좋습니다. 페이지 레이아웃 섹션을 참조하여 더 이상 개선하지 않을 이유에 대한 자세한 내용을 확인하십시오.
• 테이크아웃 #2: 정확히 하나의 개체에 대한 만들기 또는 편집 양식을 작성해야 하는 경우 Lightning 페이지 및 동적 양식으로 시작합니다. Salesforce Platform에서 양식을 작성하는 가장 간단한 방법입니다. 또한 필드 가시성을 제어하는 기능과 같은 몇 가지 추가 기능도 제공합니다. 요구 사항이 더 고급 경우 계속 읽으십시오. 화면 플로, OmniStudio 또는 Lightning 웹 구성 요소(LWC)가 더 적합할 수 있습니다.
• 테이크아웃 #3: 다중 페이지 양식 또는 마법사를 작성하고 있으며 엄격한 UX 또는 브랜딩 요구 사항이 없는 경우 화면 플로로 시작하십시오. 화면 플로는 여러 양식을 함께 오케스트레이션할 수 있는 선형 탐색 프레임워크를 제공합니다. LWC를 사용하여 양식 간에 탐색할 수 있는 자체 프레임워크를 구축할 수 있지만, 형식 상태에 대해 걱정하지 않고 양식 자체에 집중할 수 있도록 Flow가 당신을 위해 힘든 작업을 수행하는 것이 좋습니다.
• 테이크아웃 #4: 추가 논리 또는 작업이 필요한 경우 화면 플로, OmniStudio 또는 LWC를 사용하십시오.** 세 가지 도구 모두 솔루션이 단일 레코드를 만들거나 편집하는 것 이상의 작업을 수행할 수 있는 방법을 제공합니다. 해당 "더"는 분기 또는 반복과 같은 더 고급 논리일 수 있으며, 외부 시스템과 통합, 이메일 보내기 또는 사용자의 모바일 앱에 알림 푸시와 같은 더 많은 작업일 수 있습니다.
• 테이크아웃 #5: 정교한 UX 요구 사항이 있습니까? 가시성 이상을 동적으로 처리해야 합니까? LWC 또는 Omniscript를 사용합니다. 간단한 테마 및 열 기반 레이아웃으로 요구 사항을 충족할 수 있는 경우 하위 코드 빌더에서 직접 양식을 작성할 수 있습니다. 양식의 스타일을 더욱 세분화적으로 제어하려면 LWC의 최상의 유연성이 필요합니다. 산업 고객이며 픽셀 퍼펙트 브랜딩이 필요하거나 복잡한 계층 데이터가 있는 경우 OmniStudio를 사용하여 복잡한 비즈니스 논리 및 데이터 변환을 처리할 수 있는 소비자 등급 양식을 구축할 수 있습니다.
• 테이크아웃 #6: 테스트 자동화가 필요한 경우 Lightning 웹 구성 요소로 시작하십시오. 포함할 위치와 상관없이 LWC에 대한 단위 테스트를 작성할 수 있습니다. 이를 통해 여러 레코드가 있는 대량 테스트 및 음수 테스트를 포함할 수 있는 더 강력한 테스트 전략을 만들 수 있습니다. 양식이 기능 및 비 기능 요구 사항에 얼마나 잘 부합하는지 확인할 수 있는 테스트를 만드는 방법에 대한 자세한 내용은 Salesforce Well-Architected - Testing Strategy를 참조하십시오.

선택 항목 중 하나가 될 필요가 없으므로 여러 옵션을 결합할 수 있습니다. 예를 들어, 플로의 내장형 탐색 시스템과 LWC가 제공하는 전체 스타일 지정 유연성이 모두 필요한 경우 함께 사용하십시오.

아래 표는 Salesforce로 양식을 작성하는 데 사용할 수 있는 도구와 필수 기술 및 라이센스 고려 사항을 간략하게 보여줍니다. 나중에 각 도구에 대해 지원되는 특정 기능과 클릭 기반 도구와 코드 기반 도구 간에 선택하는 방법(및 결합 시점)을 자세히 살펴보겠습니다.

아래 표에는 제품을 선택할 때 고려해야 할 결정 지점의 개요와 각각에 대해 자신에게 질문해야 하는 질문이 포함되어 있습니다. 이 가이드의 나머지 부분에서 각 주제를 자세히 살펴볼 것입니다.

다음은 비교 테이블에서 정의와 함께 사용하는 용어입니다.

• 사용 가능: 기본 고려 사항과 함께 작동합니다.
• ** 이상적이지 않음:** 작동할 수 있지만 최적의 도구는 아닙니다.
• 로드맵: 향후 12개월(2025년 6월) 이내에 지원 예상
• 미래: 향후 12개월 이후 지원 예상
• 사용 불가: 향후 12개월 이내에 이 기능을 지원할 계획이 없습니다.

약속대로 동적 양식, 화면 플로, OmniStudio, 내장형 LWC가 있는 화면 플로, LWC 프레임워크 자체 간의 다양한 비교 지점과 기능적 차이점을 자세히 살펴보겠습니다.

양식이 단일 Salesforce 개체에 대해 작동하는 경우 비교하는 도구가 작동합니다. 교차 개체 또는 개체가 없는 형태로 인해 상황이 조금 더 복잡해집니다. 개체 비정의는 Salesforce 개체에 매핑되지 않는 입력을 의미합니다. 양식은 Stripe 또는 DocuSign과 같은 외부 서비스에 보낼 데이터 구조를 나타낼 수 있습니다. 또는 양식에서 여러 입력을 사용하여 값을 계산한 다음, 데이터베이스에 해당 값을 커밋합니다.

• 양식이 작동하는 개체는 무엇입니까?
• 개체가 하나일까요? 개체가 여러 개입니까?
• 특정 개체(예: 계정, 연락처, 기회, 리드 및 사례)로 작업하거나 양식이 다른 개체에서도 작동해야 합니까?

교차 개체 및 개체 비호 양식의 경우 Flow 및 OmniStudio는 모두 솔리드 옵션입니다. 플로 화면에서 사용할 수 있는 구성 요소는 본질적으로 무시적이므로 해당 데이터를 사용하여 수행할 작업을 선택할 수 있습니다. 예를 들어, 하나의 양식에 입력한 데이터를 사용하여 여러 레코드를 만듭니다. 또는 Chatter 게시물 생성, Slack 메시지 보내기, 이메일 보내기 또는 외부 서비스에 연결하는 등 다른 작업을 수행합니다.

간단한 경우 Lightning 같은 기존 LWC 구성 요소를 사용하면 강력한 솔루션을 제공하기 위해 필요한 코드를 낮출 수 있습니다. 그러나 여러 개체가 포함된 시나리오의 경우 플로에서 모든 개체를 포괄적으로 제어하고 개발자가 복잡한 관계 및 종속성을 살펴볼 필요가 없습니다.

OmniStudio는 한 단계 더 나아가 완전히 개체 무시적이며 사용자에게 표시되는 양식을 기본 데이터 모델과 구분합니다. 대신 OmniStudio는 데이터 매퍼 및 통합 절차와 같은 도구를 사용하여 Salesforce 개체(또는 외부 데이터)에 매핑되는 기본 JSON을 조작합니다. 데이터 매퍼 및 통합 절차는 OmniStudio 양식을 Salesforce 내부 및 외부 데이터와 연결하는 두 가지 핵심 구성 요소입니다. 끌어서 놓기 요소를 사용하면 외부 시스템에서 복잡한 계층 데이터로 작업한 다음, 데이터가 이동해야 하는 위치에 따라 필요에 맞게 데이터를 변환할 수 있습니다. 또한 수식을 사용하여 배열 또는 Apex 같은 데이터 목록에서 수학 및 논리를 수행할 수도 있습니다.

OmniStudio 통합

단일 화면 양식에서 모든 사용자 입력을 가져올 수 있는 경우 동적 양식부터 시작합니다. 그러나 레코드 페이지의 동적 양식은 경로 기능을 사용하여 비즈니스 프로세스의 다양한 단계를 느슨하게 나타낼 수 있지만, 대부분의 사용 사례에 적합하지 않을 수 있습니다.

• 단일 화면이 필요합니까? 과업을 완료하려면 사용자가 여러 화면 사이를 탐색해야 합니까?
• 사용자가 양식을 작성하는 과정에서 얼마나 진행되었는지 시각적으로 설명하도록 하시겠습니까?
• 사용자가 각 화면의 정보를 특정 순서로 작성해야 하거나 필요에 따라 화면 간에 앞뒤로 이동할 수 있어야 합니까?

동적 양식에서 제공하는 것보다 더 많은 기능이 필요한 경우 플로, OmniStudio, LWC 간 선택 항목은 몇 가지 다른 질문에 따라 다릅니다.

• 팀은 어떤 기술을 보유하고 있습니까? 관리자가 많은 조직의 경우 플로로 시작하는 것이 좋습니다. 산업 솔루션이 있는 경우 팀에서 이미 OmniStudio에 익숙하며 프로젝트에 엄격한 UX 요구 사항이 있는 경우 OmniStudio부터 시작합니다.
• 양식 하단에 탐색 모음을 표시할 수 있습니까? 화면 플로 및 Omniscript 탐색 환경이 바람직하지 않은 UX인 경우 LWC로 이동합니다.
• 양식 뒤에 수행해야 하는 작업은 무엇입니까? 관리자가 동작을 구성할 수 있어야 하는 경우 플로를 구축하거나 필드 레이블 변경과 같은 기본 변경의 경우 Omniscript를 구축합니다. 그렇지 않으면 복잡한 다중 개체 관계의 경우 Omniscript 또는 LWC를 구축합니다.
• 플로 또는 OmniStudio를 선택하는 경우 적절한 UX를 위해 LWC를 구축해야 할 수 있습니다. 이미 양식의 스타일을 올바르게 지정하기 위해 LWC를 구축 중인 경우 플로에 해당 구성 요소를 포함하는 작업이 과도한 것인지 고려하십시오.

반면, 솔루션이 마법사처럼 보일 경우 사용자가 여러 화면 사이를 탐색하는 경우 플로 또는 OmniStudio를 고려하십시오. 플로 및 OmniStudio는 내장 탐색 모델과 함께 제공되므로 함께 연결된 LWC를 구축하고 유지할 필요가 없습니다. 탐색은 선형이며 앞으로 이동하는 작업, 뒤로 이동하는 작업 및 나중에 양식을 저장할 수 있는 메커니즘이 있습니다. 목적에 맞는 경우 비선형 탐색을 사용하여 양식을 작성할 수도 있습니다. 화면 플로를 사용하는 좋은 예는 Salesforce Labs의 디지털 매장 감사 패키지를 참조하십시오.

OmniStudio는 양식에 '단계'를 표시하는 표준 탐색의 진행률 표시기를 제공하여 주요 탐색 이점을 제공합니다. 이 단계 보기는 사용자가 지정된 다단계 양식에 있는 위치를 자동으로 표시합니다. 플로와 달리 사용자는 양식의 다양한 단계를 클릭하여 화면 간에 '건너뛰기'할 수 있습니다.

단일 화면 또는 다중 화면 양식을 만드는지 여부와 상관없이 양식이 사용자가 쉽게 탐색할 수 있도록 간소화되어 있는지 확인하십시오.

표준 Lightning 레코드 페이지에 양식을 포함하는 경우 비교하는 모든 도구가 작동합니다. 동적 양식은 현재 데스크톱에서만 사용할 수 있다는 점에 유의하십시오. 그러나 사용자가 다른 위치에서 양식에 액세스할 수 있는 환경을 제공하려는 경우 대체 옵션을 고려해야 할 수 있습니다.

• 사용자가 데스크톱, 모바일 또는 둘 모두를 통해 양식에 액세스해야 합니까?
• 사용자가 유틸리티 막대를 통해 앱의 모든 위치에서 양식에 액세스할 수 있어야 합니까?
• 사용자가 현재 있는 페이지에서 이동하지 않고도 양식을 작성할 수 있도록 빠른 작업을 사용하려고 합니까?
• 외부 웹 사이트에서 양식을 사용할 수 있어야 합니까?

동적 양식은 Lightning 레코드 페이지에서만 지원되므로 레코드 컨텍스트가 필요합니다. 그러나 Experience Cloud 페이지에서는 동적 양식이 지원되지 않습니다. Experience Cloud는 동적 양식이 종속되는 기본 프레임워크를 사용하지 않으므로 이 제한 사항이 적용됩니다. Lightning 페이지. Experience Cloud의 동적 양식 요청을 기반으로 이를 평가하고 있습니다.

레코드 컨텍스트가 필요한 플로 또는 전역적으로 작동하는 플로를 구축할 수 있습니다. 따라서 다양한 위치에 플로를 포함할 수 있습니다. 레코드 컨텍스트 플로의 경우 Lightning 레코드 페이지, Experience Cloud 레코드 페이지, 개체별 작업 또는 작업 및 권장 사항 배포일 수 있습니다. 전역 플로의 경우 유틸리티 막대, 기타 Lightning 또는 익스피리언스 빌더 페이지, Snap 또는 외부 응용 프로그램일 수 있습니다. 플로는 현재 전역 작업으로 지원되지 않지만 해결 방법으로 Aura 구성 요소에 플로를 래핑할 수 있습니다.

OmniStudio를 사용하면 플로를 배치할 수 있는 거의 모든 위치에 배치할 수 있는 구성 가능한 FlexCard 및 Omniscript를 구축할 수 있습니다. 그러나 구성할 수는 있지만 패키징할 수는 없습니다.

LWC는 Salesforce, 커뮤니티 전체, 오픈 소스 프로젝트에서도 메타데이터를 통해 대상과 연결할 수 있는 구성 요소를 만들기 때문에 높은 수준의 재사용성을 지원합니다. LWC 구성 요소는 Lightning Out을 통해 자체 웹사이트 내부에 포함할 수도 있습니다.

External Sites에서 Lightning Out

Lightning 웹 구성 요소는 현재 빠른 작업(개체별 또는 전역)으로 지원되지 않지만, 해결 방법으로 LWC를 Aura 구성 요소에 래핑할 수 있습니다(플로와 마찬가지로). LWC 구성 요소는 또한 Lightning-flow 구성 요소로 흐름을 시작할 수 있습니다.

OmniStudio는 OmniOut 기능을 통해 외부 사이트에 콘텐츠를 노출하는 데 우수합니다. OmniStudio 및 OmniOut을 사용하면 OmniScript 양식 및 FlexCard 구성 요소를 표준 구성 요소로 컴파일하고 타사 사이트 또는 앱에서 플랫폼 외부에서 실행할 수 있습니다.

이 가이드에 포함된 양식 기술은 현재 Mobile SDK 템플릿에서 공식적으로 지원되지 않습니다. Mobile SDK가 사용 사례에 필수적이라면 Salesforce Well-Architected form factor 지침을 염두에 두고 모바일 응용 프로그램에서 기본적으로 양식을 작성하거나 Visualforce 페이지를 작성하는 것이 좋습니다.

로드맵 참고: Mobile SDK 팀은 Visualforce 페이지 내에서 LWC를 지원하는 데 적극적으로 노력하고 있습니다.

동적 양식은 양식에서 값을 사용하여 레코드를 만들거나 업데이트해야 하는 경우에 적합합니다. 이외의 기능을 사용하려면 플로, OmniStudio 또는 LWC를 활용해야 합니다. 이러한 기능에는 결정 또는 반복 계층 또는 양식의 입력을 사용하여 Slack 게시물 또는 이메일 생성이 포함될 수 있습니다.

• 백그라운드에서 수행하려는 작업 또는 논리는 무엇입니까?
• 데이터 모델에 계층적 데이터가 포함되어 있습니까?
• 단일 트랜잭션 또는 여러 트랜잭션에서 양식의 작업을 완료해야 합니까?
• 외부 시스템과 통합해야 합니까?
• 재사용 가능성 및 모듈성에 대한 요구 사항은 무엇입니까?

Flow는 Slack에 게시, 이메일 보내기 및 Quip 문서와 상호 작용을 위한 표준 작업을 제공하므로 이러한 작업에 코드를 작성할 필요가 없습니다. LWC는 사용자 인터페이스 API와 상호 작용하는 유선 어댑터를 사용하여 단일 레코드 및 관련 객체와 풍부한 상호 작용을 제공합니다. 또한 LWC는 getListInfoByName의 유선을 사용할 때 여러 레코드와 상호 작용할 수 있습니다.

Lightning 웹 구성 요소 유선 어댑터를 통한 상호 작용

위에서 언급한 것처럼 OmniStudio는 통합 절차 및 데이터 매퍼를 사용하여 외부 및 내부 데이터를 쉽게 캡처하고 Salesforce로 변환합니다. 사용 가능한 수많은 코드가 없는 기능 덕분에 다양한 수준의 관계를 갖춘 데이터 집합을 평면화하고 확장할 수 있습니다.

로드맵 참고: 플로는 곧 레코드 컬렉션을 업서트하고 계층적 데이터를 관리하는 기능을 지원합니다.

Flow, OmniStudio, LWC는 모두 Apex 통합되므로 선택한 솔루션에서 간편하게 격차를 해소할 수 있습니다. 예를 들어, LWC에서 레코드를 필터링해야 하는 경우 항상 Apex 유선 어댑터를 사용하여 복잡한 SOQL 쿼리를 만들 수 있습니다. 클릭 기반 스토리로 인해 영향을 받는 경우 서버 측의 요구에 맞게 Apex 컨트롤러의 실용적인 대안으로 Flow 또는 OmniStudio를 고려하십시오.

여기서 두 번째 질문은 작업을 즉시 커밋할 것인지 또는 작업을 양식의 특정 부분으로 연기할 것인지 여부입니다. 이는 다중 페이지 양식인 경우 특히 유용합니다. 플로를 사용하면 여러 양식(플로 화면)의 입력을 쉽게 결합하고 마법사(플로)에서 훨씬 나중에 사용하여 일부 작업을 수행할 수 있습니다. 실제로 사용자가 화면 간에 앞뒤로 반전하여 답변을 변경할 경우 플로를 이 방식으로 설계하는 것이 좋습니다.

트랜잭션 및 관리 제한은 Salesforce Platform에서 생활 방식입니다. 사용 사례가 상당히 간단한 경우 특정 작업이 발생하는 트랜잭션을 제어하는 것이 중요하지 않을 수 있습니다. 그러나 여러 작업을 여러 트랜잭션에 걸쳐 수행하는 대신 여러 작업을 하나의 트랜잭션에 결합할 수 있는 몇 가지 사용 사례가 있습니다. 몇 가지 예:

• Rollback 또는 Not to Rollback: 바로 질문입니다. 양식이 백그라운드에서 여러 레코드를 생성한다고 가정합니다. 세 번째 레코드를 만들지 못할 경우 처음 두 개의 레코드를 롤백해야 합니까? 각 작업이 서로 독립적인 경우 별도의 트랜잭션에서 실행할 수 있습니다. 그러나 종속적이고 하나의 실패로 인해 다른 항목도 롤백되도록 하려는 경우 단일 트랜잭션에서 구현합니다. 양식이 플로에 있는 경우 오류 경로의 롤백 요소를 사용하여 트랜잭션을 롤백하고 데이터 무결성을 보장할 수 있습니다.
• Governor Limits에 대한 다운스트림 영향: 특히 양식에서 레코드를 만들거나 업데이트하는 경우 해당 작업의 다운스트림 영향을 고려하십시오. 이 레코드 변경에 따라 어떤 프로세스, 워크플로 규칙, 플로 트리거, Apex 트리거 또는 저장 순서의 다른 항목이 실행될 것입니까? 이러한 집합 변경 사항은 해당 트랜잭션에서 사용되는 총괄자 제한에 어떤 영향을 미칩니까? 특정 레코드 변경으로 인해 제한에 영향을 미치는 많은 다운스트림 변경 사항이 발생할 경우 해당 레코드 변경 사항을 자체 트랜잭션으로 분리하는 것이 좋습니다.
• 배치 처리: UI 컨텍스트에서도 여러 업데이트를 함께 배치해야 할 수 있습니다. 다중 화면 양식이 대규모 레코드 그룹에서 반복되는 경우 각 화면 이후에 레코드 업데이트를 커밋하는 대신 모든 레코드에 대한 업데이트를 수집할 때까지 기다린 다음, 모든 레코드를 업데이트하기 위한 한 번의 요청을 제출합니다.

동적 양식을 사용하여 레코드를 만들거나 편집하는 경우 한 번만 작업을 수행하고 해당 작업은 항상 순 새 트랜잭션의 시작입니다.

화면 플로를 구축할 때 지정된 트랜잭션에서 수행되는 작업을 크게 제어할 수 있습니다. 화면 및 로컬 작업은 트랜잭션 간 경계 역할을 합니다. 다음은 화면 플로 아키텍처에서 트랜잭션이 관리되는 방법에 대한 상위 수준 요약입니다.

1. 최종 사용자가 화면과 상호 작용한 다음, 다음을 클릭합니다.
2. 클라이언트가 입력과 함께 API에 요청을 게시합니다.
3. API가 요청을 수신하고 트랜잭션 및 데이터베이스 연결이 열립니다. 그런 다음, API가 플로 엔진을 호출하여 요청을 호출합니다.
4. 플로 엔진이 화면 또는 로컬 작업 노드에 도달할 때까지 플로 정의의 적절한 경로를 차지하고 따릅니다. 엔진이 해당 노드에 대한 정보를 API에 반환합니다.
5. API가 렌더링할 다음 화면의 세부 사항을 포함하는 응답 개체를 만들고 클라이언트에게 해당 개체를 반환합니다. 이 시점에서 데이터베이스 변경 사항이 커밋되고(주문 저장 실행) 데이터베이스 연결 및 트랜잭션이 종료됩니다.
6. 클라이언트가 API 응답을 사용하여 사용자가 상호 작용할 다음 화면을 렌더링합니다.
7. 1단계에서 반복합니다.

다시 말해, "중단" 트랜잭션을 표시합니다. 이러한 경우 보류 중인 작업 또는 DML이 커밋되고 이전 트랜잭션이 마감되고 새 트랜잭션이 시작됩니다.

지정된 트랜잭션에 그룹화하는 작업에 대한 올바른 설계는 호출입니다. 몇 가지 예를 살펴보겠습니다.

왼쪽에서 여러 화면에서 입력을 수집한 다음, 하나의 트랜잭션에서 여러 작업을 수행하는 플로를 볼 수 있습니다.

오른쪽의 플로는 별도의 트랜잭션에서 각 작업을 수행합니다.

오른쪽의 다음 플로에 표시된 것처럼 레코드를 생성하고, 레코드를 업데이트한 다음, 더 많은 레코드를 생성하는 플로가 있다고 가정합니다.

이 시나리오에서 처음 두 개의 요소가 성공하고 마지막 두 개의 요소가 실패하면 처음 두 개의 DML 작업이 해당 레코드를 만들고 업데이트하지만 세 번째 작업은 실패합니다.

레코드 롤백 요소를 사용하면 왼쪽의 최종 플로에 표시된 것처럼 세 가지 작업을 모두 동시에 수행해야 하는 경우 전체 트랜잭션이 롤백되는지 확인할 수 있습니다.

자세한 내용은 트랜잭션 플로 및 트랜잭션 플로 대량 처리을 참조하십시오. Salesforce Well-Architected의 Automated 섹션은 또한 데이터 처리에 대해 자세히 설명합니다.

LWC에서 트랜잭션을 제어하는 기능은 LWC가 작업을 수행하는 데 사용하는 기본 서비스에 속합니다. Lightning 기본 구성 요소를 사용하는 경우 양식이 제출된 즉시 독립형 트랜잭션에서 기본 작업(레코드 만들기 또는 업데이트)이 수행됩니다.

일반적으로 다음 규칙이 적용됩니다.

• 각 UI API 호출은 자체 트랜잭션으로 분리됩니다.
• 단일 트랜잭션 내에서 여러 작업을 수행해야 하는 경우 입력 내용을 Apex 컨트롤러 또는 플로와 같은 서버측 기술로 보냅니다. 해당 기술에 대한 일반 트랜잭션 규칙이 적용됩니다.

Flow, OmniStudio 및 LWC는 모두 플랫폼 이벤트(이벤트 기반 아키텍처) 및 API 통합을 지원합니다. 사용자 정의 Apex 코드 외에도 Flow 및 OmniStudio는 API를 통합하기 위한 선언적 메커니즘을 모두 지원합니다.

Mulesoft API 또는 RPA Bot에 연결해야 하는 경우 Mulesoft 서비스를 사용하십시오. 이렇게 하면 외부 서비스가 생성됩니다.

Mulesoft API 및 RPA Bots를 통한 외부 통합

API에 OpenAPI 스키마가 있는 경우 외부 서비스를 만듭니다.

OpenAPI 스키마를 사용하는 API에 대한 외부 통합

그렇지 않으면 플로의 HTTP 콜아웃 기능 또는 OmniStudio의 HTTP 작업을 사용합니다. 플로의 HTTP 콜아웃은 외부 서비스에서 제공됩니다.

HTTP를 통한 외부 통합

OmniStudio는 통합 절차를 통해 외부 시스템에 콜아웃하고 데이터 매퍼를 사용하여 데이터를 변환할 수 있는 다양한 통합 기능을 제공합니다. (자세한 내용은 개체 영향을 참조하십시오.)

사용자 정의 Apex 또는 외부 서비스로 구현하든 상관없이 콜아웃은 콜아웃입니다. 다음은 알아야 할 사항입니다.

1. 콜아웃에는 시간이 오래 걸릴 수 있습니다.
2. 콜아웃이 동기식으로 실행되면 데이터베이스 트랜잭션이 열려 있는 동안 수행됩니다.
3. 보류 중인 데이터베이스 작업이 있는 경우 Salesforce에서 데이터베이스 트랜잭션을 열어 둘 수 없습니다.

주된 제한 사항은 소위 **나쁜 거래**의 위험입니다. 여기서 생성, 업데이트 또는 삭제 작업을 수행한 다음, 동일한 거래에서 콜아웃을 실행합니다. 위의 고려 사항 #3이므로 이 패턴은 허용되지 않습니다. 이는 고려 사항 #1 및 #2 때문에 물론 존재합니다.

플로에서 트랜잭션을 중단하여 이 제한을 해결할 수 있습니다. 화면 및 로컬 작업이 모두 브라우저 컨텍스트를 다시 도입하여 트랜잭션을 중단한다는 점에 유의하십시오. 외부 콜아웃으로 작업할 때 화면 및 로컬 작업을 사용할 수 있지만 호출 가능한 고급 설정에서 트랜잭션 제어를 활성화하는 것이 좋습니다. 트랜잭션 제어는 콜아웃을 만들기 전에 트랜잭션을 자동으로 종료할 수 있는 호출 가능한 작업의 기능입니다. 호출된 작업의 고급 섹션에서 항상 새 트랜잭션 시작을 선택하여 트랜잭션 관리를 활성화할 수 있습니다.

Apex 콜아웃, 외부 서비스 및 일반 데이터 통합 기능에 대한 자세한 지침은 Salesforce와 데이터 통합을 위한 아키텍트 가이드를 참조하십시오.

동적 양식은 재사용을 지원하지 않습니다. 각 동적 양식은 특정 개체에 대한 특정 Lightning 레코드 페이지에 연결됩니다(여러 앱, 프로필 등에 해당 Lightning 레코드 페이지를 할당할 수 있음).

여러 다른 구성 요소에서 사용할 라이브러리, 유틸리티 및 구성 요소를 작성할 수 있는 것과 마찬가지로 **하위 플로**의 기능을 사용하여 플로를 만들 때 비슷한 디자인 패턴을 적용할 수 있습니다. 더 작은 모듈식 버킷에 플로를 저장한 다음, 서브플로 요소를 사용하여 다른 플로에서 플로를 호출합니다. 설계에 필요할 경우 자체적으로 지원되고 다른 플로의 하위 플로로 유용한 플로를 구축할 수 있습니다.

OmniStudio는 기본적으로 모듈성을 위해 구축되었습니다. 데이터 매퍼, OmniScript, FlexCard 및 통합 절차는 모두 독립적으로 구축되며 상호 교환적으로 작동할 수 있습니다. 또한 FlexCard는 다른 LWC, Omniscript, 레코드 페이지, Experience Cloud 사이트에 포함할 수 있는 LWC 구성 요소로 구축할 수 있습니다.

화면 플로, Omniscript 및 LWC는 모두 재사용할 수 있으며 외부 사이트 및 Lightning Out 애플리케이션을 비롯한 다양한 위치에 내장할 수 있습니다. 솔루션을 조립 가능하게 설계하면 적응성 및 안정성과 같은 추가적인 이점을 얻을 수 있습니다.

레코드를 만들거나 업데이트하는 데 사용되는 모든 기술은 기존의 검증 규칙이든 Apex 트리거에 내장된 사용자 정의 검증이든 시스템 수준의 검증을 준수합니다. 레코드 변경을 수행하는 데 사용하는 기술과 상관없이 모든 변경 사항은 저장 주문을 통해 전달됩니다. 즉, 확인 규칙 외에도 레코드 변경 사항은 트리거 전후, 에스컬레이션 규칙, 할당 규칙 등과 같은 여러 저장 전후 플로에서 처리됩니다. 아직 작성하지 않은 경우 북마크를 지정하고 Apex 실행 순서에 익숙해지십시오.

• 시스템 수준 확인 외에도 양식에 추가 요구 사항이 있습니까?
• 양식 내에서 필드를 필수 또는 읽기 전용으로 동적으로 설정해야 합니까?

플로 화면 또는 Omniscript 단계의 입력은 본질적으로 제한되지 않으므로 양식 자체가 특정 개체와 관련된 시스템 수준 확인을 기본적으로 준수하지 않습니다. 그러나 레코드를 만들거나 업데이트하는 데 사용하는 값은 저장 순서에 의해 처리되므로 개체의 시스템 수준 확인을 통과합니다. 그러나 일부 화면 플로 구성 요소는 입력 유효성 검사를 지원하지 않는다는 점에 유의하십시오. Summer '24부터 입력 유효성 검사를 지원하지 않는 나머지 화면 구성 요소는 라디오 버튼, 선택 목록, 다중 선택 선택 목록, 확인란 그룹, 선택 항목 조회입니다.

페이지 레이아웃과 마찬가지로 동적 양식을 사용하면 페이지 수준에서 필수성 및 읽기 전용 상태를 설정할 수 있습니다. 그러나 시스템 수준 설정을 재정의할 수 없습니다.

플로는 양식의 입력에 대한 유효성 검사를 유연하게 사용자 정의할 수 있습니다. 클라이언트에서 일부 확인을 수행하는 경우(예: 누락된 필수 필드 또는 호환되지 않는 값에 플래그 지정) 클라이언트측 확인은 사용자의 탐색을 차단하지 않습니다. 실제 유효성 검사는 서버에서 수행됩니다. 사용자가 다음을 클릭하면 Flow가 확인을 위해 서버에 입력을 보냅니다. 입력이 잘못된 것으로 반환되는 경우 탐색이 차단되고 적절한 오류가 표시됩니다. 서버가 다음을 확인하여 입력을 확인합니다.

1. 입력의 필수성 설정 또는 입력한 값이 기본 데이터 유형과 호환되는지 여부입니다.
2. 해당 입력에 대한 사용자 정의 유효성 검사: 여러 표준 구성 요소(확인란, 통화, 날짜, 날짜/시간, 긴 텍스트 영역, 숫자, 암호, 텍스트)는 화면별로 사용자 정의 유효성 검사를 지원합니다. 수식이 충족되지 않을 경우 표시할 부울 수식 및 오류 메시지를 제공합니다.
3. 기본 구성 요소에 대한 사용자 정의 확인: 플로에 대한 사용자 정의 LWC를 구축하는 경우 validate() 메서드에 자체 확인 코드를 추가합니다.

OmniStudio는 조건부 보기 및 메시징 구성 요소와 함께 오류 설정 작업을 통해 풍부한 오류 및 검증 처리를 제공합니다.

LWC 측에서는 대부분의 기본 구성 요소가 자체 클라이언트측 유효성 검사를 수행합니다. 예를 들어 Lightning 페이지 수준 필수 항목이 아닌 시스템 수준 필수 항목을 준수합니다. 사용자 정의 구성 요소에 대해 Build Your Own 검증 메커니즘을 만들 수 있습니다.

사용자가 데이터를 입력해야 하는 필드는 양식에 조기에 표시되어야 합니다. 가능한 경우 양식을 제출하기 전에 클라이언트 측에서 사용자 입력을 확인합니다. 양식 간소화에 대한 추가 모범 사례는 Salesforce Well-Architected - Engaging의 양식 지침을 참조하십시오.

보안은 일반적으로 복잡한 주제이며 양식 구축과 관련하여 고려하지 않은 여러 가지 고려 사항이 있습니다. 기본 수준에서 양식이 올바른 컨텍스트에서 실행되고 사용자에게 기본 데이터에 대해 작업하는 데 필요한 권한이 있는지 확인하려고 합니다. 그러나 추가 조치를 취하여 서식 있는 텍스트 필드에서 잠재적으로 악성 코드 또는 URL을 제거하고 특정 사용자가 양식에 액세스할 수 없게 하거나 관리자가 향후 양식을 포함할 수 있는 위치 유형에 제한을 적용할 수도 있습니다. 도구를 선택하기 전에 보안 요구 사항을 철저하게 문서화해야 합니다. Salesforce 잘 구축된 보안 정책 템플릿에는 이 유형의 문서에 대한 지침이 포함되어 있습니다.

• 특정 작업을 수행하기 전에 양식에서 사용자의 액세스를 확인해야 합니까?
• 사용자 입력을 비활성화해야 합니까?
• 양식에 액세스할 수 있는 사람을 제어하려는 경우
• 양식을 포함할 수 있는 위치를 제어하려는 경우

**사용자 컨텍스트**에서 실행되는 경우 Salesforce는 조직의 공유 규칙을 기반으로 필드 수준 보안, CRUD 권한 및 레코드 액세스를 확인하는 등 일련의 액세스 검사를 적용합니다. 예를 들어 사용자는 사례를 업데이트할 수 있는 기능, 적절한 필드 수준 보안, 관련 레코드에 대한 액세스 권한이 있는 경우에만 사례 업데이트 양식을 실행할 수 있습니다. 그러나 사용자가 다른 양식이나 상호 작용을 통해서가 아닌 당사 양식을 사용할 때 특정 작업을 수행할 수 있도록 하려면 어떻게 해야 합니까? 여기서 **시스템 컨텍스트**가 들어옵니다.

시스템 컨텍스트는 사용자가 사례 업데이트 양식을 성공적으로 완료하기 위해 사례 개체에 대한 액세스 업데이트와 같이 필요하지 않도록 세션 기간 동안 실행 중인 사용자의 권한을 높이는 방법입니다. 이는 특히 인증되지 않은 커뮤니티에 유용합니다. 게스트 사용자에게 잠재적으로 위험한 기능을 부여하는 대신 시스템 컨텍스트에서 실행되도록 양식을 설정합니다.

물론 시스템 컨텍스트는 양쪽 가장자리 검이며 필요한 경우에만 사용해야 합니다. 시스템 컨텍스트에서 양식이 실행되면 모든 단일 CRUD 작업이 관심 있는 특정 작업뿐만 아니라 개체 및 필드 수준 보안 및 공유를 우회합니다. 또한 시스템 컨텍스트는 Salesforce에서 작업자로 간주하는 사람(마지막 수정자 필드에 표시되는 이름)에 영향을 미치지 않습니다. 사례 업데이트와 같이 양식이 수행하는 각 작업에 대해 작업자는 양식이 다른 컨텍스트에서 실행되는 경우에도 실제 사용자입니다.

동적 양식, OmniScript 및 LWC는 항상 사용자 컨텍스트에서 실행되며 이 동작을 재정의할 수 있는 방법은 없습니다.

화면 플로는 기본적으로 사용자 컨텍스트에서 실행되지만 시스템 컨텍스트에서 실행되도록 설정할 수 있습니다. 플로에서 모든 데이터에 대한 액세스 권한을 부여해야 하는지 아니면 공유와 같은 레코드 수준 액세스를 계속 적용해야 하는지 여부를 선택할 수 있습니다.

• 시스템 컨텍스트에서 실행되는 플로에 Lightning 구성 요소를 포함하는 경우 플로가 구성 요소의 컨텍스트를 재정의하지 않습니다. 사용자 액세스 검사를 우회해야 하는 경우 플로를 사용하여 해당 작업을 수행하고 Lightning 구성 요소에 적절한 데이터를 전달하거나 전달하는 것이 좋습니다. 일부 기본 구성 요소(예: 조회)는 시스템 컨텍스트에서 작동할 수 없습니다.
• 플로에서 Apex 작업을 호출하는 경우 이해해야 할 몇 가지 요소가 있습니다. Apex 클래스가 상속된 공유로 설정된 경우 플로가 설정된 내용과 상관없이 공유와 함께 시스템 컨텍스트에서 실행됩니다. 클래스에 명시적 공유 선언이 없는 경우 플로 설정에 관계없이 공유 없이 시스템 컨텍스트에서 실행됩니다. 클래스가 공유 또는 비공유로 설정된 경우 해당 클래스가 설정되고 플로의 컨텍스트를 재정의합니다.

Experience Cloud 사이트를 사용하여 시스템 컨텍스트의 레코드 쿼리:

Experience Cloud 사이트에서 시스템 컨텍스트에서 플로를 실행하는 경우(특히 인증되지 않은 경우) 레코드 가져오기 요소에 특정 필드만 저장하는 것이 좋습니다. Flow로 작업하고 레코드 가져오기 요소의 결과를 하위 플로, 호출 가능한 작업 또는 Lightning 구성 요소로 전달하면 해당 개체의 모든 필드를 브라우저의 개발자 도구를 통해 검사할 수 있습니다. 그러면 의도하지 않은 Experience Cloud 사이트 사용자가 필드를 사용할 수 있습니다. 레코드 가져오기 요소에서 특정 필드를 지정하면 시스템 컨텍스트가 활성화된 경우에도 올바른 필드만 노출되도록 할 수 있습니다.

Omniscript 논리는 클라이언트 측에서 실행되므로 공격자는 Omniscript의 예상 실행을 수정할 수 있습니다 또는 브라우저의 개발자 도구를 사용하여 통합 절차, 데이터 매퍼 및 Apex 메서드 호출에 대한 응답을 볼 수 있습니다. Omniscript를 사용할 경우 가능한 경우 서버 측에서 비즈니스 논리를 실행하고 @InvocableMethod 주석을 통해 노출되는 모든 Apex 메서드에 입력 검증 규칙을 구현하는 것이 좋습니다.

세분화 입력:

악의적인 요인으로부터 조직을 보호하려면 입력 세분화를 고려하십시오. 조직의 서식 있는 텍스트 필드에 매핑할 수 있는 공개적으로 액세스할 수 있는 양식에 입력이 있다고 가정합니다. 악의적인 URL을 숨길 수 있는 HTML을 제외하는 자동화를 고려할 수 있습니다. 일반적으로 이러한 필드를 작성할 수 있는 소스 수가 많을 수 있으므로 양식 수준에서 이 제거를 구현하는 것이 좋지 않습니다. 빠른 필드 업데이트 플로(저장 전)를 만들거나 개체에 기존 Apex 트리거를 사용하여 양식에 입력할 수 있는 잠재적인 HTML을 제거하거나 수정하는 것이 좋습니다.

모범 사례:

• 지정된 작업에 대해 실제 사용자의 액세스 권한을 늘려야 하는 경우를 제외하고 기본 컨텍스트에서 플로를 실행하도록 합니다.
• 보안상의 이유로 게스트 사용자를 위해 시스템 컨텍스트에서 플로를 실행하지 마십시오. Experience Cloud 사이트의 게스트 사용자 프로필에 할당된 제한된 필드 액세스 권한이 있는 권한 집합을 만듭니다.
• Experience Cloud 사이트의 시스템 컨텍스트 실행 플로에서 레코드를 쿼리할 때 레코드 가져오기 요소 또는 호출 가능한 작업에 필요한 필드만 저장하십시오.
• 플로에서 다양한 작업을 수행하고 모든 작업에 상위 액세스 권한이 필요하지 않은 경우 하위 플로를 사용하여 시스템 컨텍스트에서 실행해야 하는 작업을 분리합니다.
• 외부 웹 페이지에 양식을 포함하려는 경우 서식 있는 텍스트 필드에 매핑될 경우 빠른 필드 업데이트 플로 또는 Apex 트리거를 사용하여 HTML을 제거하기 위해 사용자 입력 내용을 제거하여 악의적인 행위자의 잠재적인 피싱 공격을 방지하십시오.

• OmniScript, FlexCard, LWC는 기본적으로 사용자 컨텍스트에서 실행됩니다.
• LWC는 기본적으로 사용자 컨텍스트에서 실행되고 플로는 사용자 컨텍스트에서 실행되지만 Apex 컨트롤러에서 이를 재정의할 수 있습니다.
• UI API를 통해 수행되는 작업은 사용자 컨텍스트에서 실행됩니다.
• Apex 컨트롤러를 통해 수행되는 작업은 해당 클래스에 따라 다릅니다. 이러한 작업을 시스템 모드에서 수행하려면 Apex 클래스를 공유 또는 공유 없이로 설정합니다.

양식에 액세스할 수 있는 사람을 제어해야 하는 경우 양식이 포함된 컨테이너를 찾을 수 있습니다. 예를 들어 특정 앱, 레코드 유형 또는 프로필에 사용할 수 있도록 Lightning 페이지를 할당할 수 있습니다. 양식의 특정 입력이 민감한 경우 가시성 규칙을 사용하여 표시할 사람에게 표시되는 내용을 세부적으로 제어합니다. 이 기능은 동적 양식과 화면 플로 모두에 적용됩니다.

Apex 클래스 또는 Visualforce 페이지처럼 특정 프로필 또는 권한 집합으로 플로를 제한할 수 있습니다. 기본적으로 플로는 제한되지 않으며, 즉 플로 실행 사용자 권한이 있는 모든 사용자가 플로를 실행할 수 있습니다.

OmniStudio를 사용하는 경우 사용자에게 Omniscript, Flexcard, Classic 카드 또는 REST API에서 호출된 원격 작업을 관리하는 Apex 클래스에 대한 명시적 액세스 권한이 필요하도록 Apex 클래스 권한 검사기를 구성할 수 있습니다.

• 참고 새로 만든 스크립트에 대해 Apex 클래스 권한 확인이 기본적으로 활성화되어 있습니다. 그러나 기존 스크립트에 대해 수동으로 활성화해야 합니다.
• 또한 Apex 클래스 권한 확인은 Apex 클래스에만 적용됩니다. 통합 절차 및 데이터 매퍼에 대해서도 프로필 수준 권한을 설정하는 것이 좋습니다.

게스트 사용자 권한에 대한 자세한 내용 및 모범 사례는 다음을 참조하십시오.

• 게스트 사용자 레코드 액세스 모범 사례
• 보안 사이트 개발: 인증된 사용자 및 게스트 사용자

모범 사례:

• 게스트 사용자에게 플로를 노출할 경우 게스트 사용자 프로필에 필요한 플로에 대한 액세스 권한만 부여합니다. 게스트 사용자 프로필에 실행 플로를 추가할 수 있지만 위험한 행동이라고 생각합니다.
• 시스템 컨텍스트에서 작동하는 플로에 특히 주의하십시오. 이러한 플로를 특정 사용자 집합으로 제한하는 것이 좋습니다. 이들은 데이터를 보호하기 위해 적은 검사 및 균형을 사용합니다.
• 게스트 사용자 커뮤니티에서 Apex를 실행하는 모든 Omniscript에 Apex 클래스 정의에 "공유"가 있는지 확인하십시오.
• 게스트 사용자 프로필에서 게스트 사용자가 호출할 수 있도록 하려는 Apex 클래스만 할당하거나 의도치 않게 게스트 사용자에게 추가 비즈니스 논리를 노출할 위험이 있습니다.

LWC의 경우 실제 사용자의 권한 할당을 확인하여 특정 표준 또는 사용자 정의 권한이 있는지 확인할 수 있습니다. JavaScript에서 직접 @salesforce/userPermission 및 @salesforce/customPermission 범위 모듈에서 Salesforce 권한을 가져올 수 있습니다. 또는 Apex 사용하여 같은 항목을 확인할 수 있습니다.

Lightning 웹 구성 요소는 지정된 위치에서 유효한 목표로 추가된 경우에만 사용할 수 있습니다. 예를 들어, 레코드 페이지에서 구성 요소를 사용 가능하고 유틸리티 막대 항목으로 사용할 수 없도록 지정할 수 있습니다.

화면 플로가 활성화되면 모든 위치에서 화면 플로를 사용할 수 있는지 여부와 상관없이 화면 플로가 지원되는 모든 위치에서 사용할 수 있습니다. 그러나 Flow Builder는 화면이 있는 여러 유형의 플로를 지원합니다. 브레드 앤 버터 유형은 화면 플로이지만 특정 위치로 제한되는 몇 가지 다른 전문 유형이 있습니다. 예를 들어, Field Service 모바일 앱은 Field Service Mobile 플로만 지원합니다(정의한 경우). Experience Cloud에서만 지원되는 연락 요청 플로에도 동일하게 적용됩니다.

플로 유형에 관계없이 플로를 만드는 개인은 플로를 포함할 수 있는 위치를 제어할 수 없습니다. 플로는 해당 플로 유형에 대해 지원되는 모든 위치에서 사용할 수 있습니다.

Salesforce Industries를 사용하는 경우 Omniscript와 관련하여 약간의 주의 사항이 있습니다. Omniscript 자체에 대한 대상을 지정할 수는 없지만 FlexCard에 포함할 수 있는 대상을 지정할 수 있습니다.

정적 양식은 과거의 형태입니다. 오늘날에는 이 사용자, 이 장소에 대해 적절한 속성 및 값을 사용하여 양식을 동적으로 업데이트해야 합니다. Salesforce의 양식 작성 도구에 대해 이 방법에서 가능한 사항에 대해 살펴보겠습니다.

• 양식 내에서 동적 응답을 트리거해야 하는 상호 작용 또는 조건 유형은 무엇입니까?
• 양식을 작성하는 동안 백그라운드에서 화면 외로 작업을 실행해야 합니까?
• 필드를 표시, 필수, 읽기 전용 또는 비활성화로 설정하거나 양식 입력을 기반으로 서식을 변경해야 합니까?

반응형 화면을 통해 화면 플로 상호 작용이 현실화되었습니다. 반응성을 사용하면 플로 화면의 개별 구성 요소가 서로 통신하므로 화면 플로가 무한히 강력해집니다.

스크린 외부 데이터 작업 실행: 화면 플로는 화면 작업을 통해 동일한 화면에서 데이터를 가져오는 선언적 접근 방식을 제공합니다. 화면 작업을 사용하면 화면의 변경 사항 또는 사용자가 작업 버튼 구성 요소를 클릭할 때 자동 실행 플로를 트리거할 수 있습니다. 그러면 자동 실행 플로의 결과를 동일한 화면에 매핑하여 사용자가 다른 화면으로 이동할 필요가 없습니다.

LWC는 Salesforce 데이터에 액세스하여 양식 구성 요소의 데이터를 동적으로 채울 수 있는 전체 배열의 유선 어댑터를 제공하며, 개발자는 Apex 컨트롤러를 통해 레코드를 업데이트, 삭제 및 생성할 수 있습니다.

Lightning 웹 구성 요소 화면 외 데이터 작업

가시성: 모든 양식 구축 도구에서 가시성을 동적으로 제어할 수 있습니다. 동적 양식, Flow Builder, OmniStudio는 구성 요소 가시성 기능을 사용하여 이를 해결합니다. 이를 사용하면 양식의 다른 값 또는 사용자가 모바일 장치에 있는지 여부를 기반으로 필드를 선언적으로 표시하거나 숨길 수 있습니다.

• 동적 양식을 사용하면 레코드 필드 값, 조회 필드를 통한 관련 레코드, 양식 요소를 기반으로 가시성을 제어할 수 있습니다.
• 플로를 사용하면 가시성 규칙을 화면의 다른 입력과 다른 레코드의 수식 또는 값과 같은 플로에서 이전에 채워진 다른 자원의 기준으로 지정할 수 있습니다.
  • 장치 기반 규칙: 처음부터 명확하지는 않지만, 사용자가 모바일 장치에 있을 때 수식을 사용하여 특정 필드를 표시하거나 숨길 수 있습니다. $User.UIThemeDisplayed 전역 변수의 값을 확인하는 플로 수식을 작성합니다. 값이 Theme4t인 경우 사용자가 Salesforce 모바일 앱에 있습니다.
  • 다른 자원 평가: 수동 변수 및 수식 참조는 서버에서만 평가됩니다. 따라서 자원이 화면을 처음 렌더링할 때 보유한 값은 다른 화면으로 이동할 때까지 보유할 값입니다. 탐색 시 플로 런타임이 플로 엔진(서버)에 요청을 제출하고 수동 변수 및 수식의 최신 값을 가져옵니다. 사용자가 단일 화면을 통과할 때 가시성 규칙이 업데이트될 것으로 예상되는 경우(예: onblur) 화면의 다른 구성 요소의 값만 참조하십시오.
• OmniStudio를 사용하면 조건부 보기 속성을 설정하여 구성 요소를 조건부로 표시하거나 숨길 수 있습니다. 그러나 입력에 대해 둘 이상의 조건부 보기 속성을 추가할 수 없습니다.

조건부 입력 상태: 필드가 필수인지, 비활성화인지 또는 읽기 전용인지와 같은 기타 속성을 동적으로 제어해야 하는 경우 몇 가지 옵션을 사용할 수 있습니다. 예상대로 LWC는 입력 상태를 완벽하게 반응형으로 제어합니다. 반응형 화면 플로 구성 요소를 사용하면 해당 구성 요소를 지원하는 표준 구성 요소에 대해 읽기 전용, 비활성화됨, 필수와 같은 구성 요소 특성을 동적으로 제어할 수 있으며, OmniStudio는 전체 구성 요소별 특성을 지원합니다. 요구 사항에 따라 플로가 필요하고 구성 요소가 특정 특성 상태를 지원하지 않는 경우 내장형 LWC를 만들어 동적 입력 상태를 달성할 수 있습니다.

필드가 필수인지 읽기 전용인지와 같은 다른 속성을 동적으로 제어해야 하는 경우 단기적으로 완벽하게 제어할 수 있는 LWC가 가장 좋습니다. 이는 특히 onblur 또는 onclick을 처리하는 방법에 대한 맞춤형 요구 사항이 있는 경우에 적용됩니다.

화면 플로의 반응형 LWC: 화면 흐름의 다른 구성 요소에 반응하거나 변경할 수 있는 LWC를 구축할 때, 이 LWC 화면 흐름용 Best Practice 가이드를 참조하여 구성 요소가 흐름 런타임 엔진 내에 잘 통합되고 향후 예상대로 작동하는지 확인하십시오.

이제 사용자 정의 이벤트입니다. 일부 입력 또는 전체 양식이 페이지의 다른 항목과 통신해야 하는 경우 LWC는 유일한 옵션입니다.

• 동일한 DOM 트리 내에서 통신하려면 CustomEvent 인터페이스를 사용합니다.
• DOM 간에 통신하려면 Lightning Messaging 서비스를 사용합니다.
• 대상 컨테이너에서 Lightning Messaging 서비스가 지원되지 않으면 파브/하위 모듈을 사용합니다.

• 자세한 내용은 Lightning 웹 구성 요소 개발 가이드에서 이벤트와 통신 및 DOM 간 통신을 참조하십시오.
• OmniStudio의 경우 Lightning 웹 구성 요소에서 Omniscript와 통신을 참조하십시오.

최상의 사용자 환경을 제공하려면 양식의 스타일이 내장된 나머지 앱 또는 사이트와 일치하는지 확인해야 합니다. 이를 수행하려면 Salesforce에서 제공하는 표준 템플릿을 활용하는 것부터 디자인의 모든 픽셀을 완전히 활용하여 더 선명한 모양과 느낌을 제공하는 사용자 정의 CSS를 만드는 것까지 다를 수 있습니다.

• 원하는 스타일 및 CSS는 얼마나 정교합니까?
• 사용자 정의된 픽셀 완벽한 스타일링이 필요합니까? 표준 테마를 사용할 수 있습니까?

FlexCard는 이 가이드에 포함된 유일한 제품으로, 여부와 상관없이 여백 및 패딩, 타이포그래픽, 색상 등 도구에서 구축하는 UI의 스타일 및 레이아웃을 선언적으로 직접 제어할 수 있습니다.

동적 양식과 플로 모두 선언적 테마 기능을 준수합니다. Salesforce 테마, 익스피리언스 빌더 브랜딩 집합 또는 LWR Experience Cloud 사이트 지원을 제어할 필요가 있는 경우 프로그래밍 솔루션을 고려하십시오.

CSS로 편하게 작업하는 팀의 경우 다음과 같은 몇 가지 옵션을 사용할 수 있습니다.

• 플로 및 LWC는 표준 설계 토큰을 상속합니다.
• OmniScript 및 FlexCard에는 사용자 정의 가능한 디자인 시스템 지원이 포함되어 있습니다. 뉴포트
• LWC를 사용하면 자체 구성 요소를 작성하고 HTML 및 CSS를 완전히 제어할 수 있습니다.

가능한 경우 모든 콘텐츠에서 모양과 느낌이 일관되게 적용되도록 테마 및 디자인 시스템을 사용하는 것이 좋습니다.

미리 알림: Lightning 구성 요소를 플로에 포함할 수 있습니다. 따라서 양식의 모양과 느낌을 픽셀 완벽하게 제어해야 하지만 탐색 모델과 같은 플로의 다른 혜택을 사용하려는 경우 두 가지 모두를 최대한 활용할 수 있습니다. Omniscript 및 FlexCard에도 동일한 원칙이 적용됩니다.

적절한 레이아웃을 선택하는 것은 빠르고 효율적인 데이터 입력을 활성화하고 데이터 무결성을 향상하는 간소화된 양식을 설계하는 데 매우 중요합니다. 이 주제에 대한 자세한 내용은 Salesforce Well-Architected - 양식을 참조하십시오.

• 양식의 레이아웃을 활용하여 사용자 환경을 최적화하는 방법은 무엇입니까?
• 사용자가 쉽게 양식에 새 데이터를 입력할 수 있도록 기존 데이터를 사용자에게 표시할 수 있는 방법은 무엇입니까?

동적 양식은 2열 레이아웃을 지원하며 필드가 있는 개별 섹션으로 나눌 수 있습니다. 이러한 섹션은 탭 및 아코디언과 같은 구성 요소에 배치하여 쉽게 사용할 수 있는 정리된 레이아웃을 만들 수 있습니다.

경우에 따라 섹션 구성 요소를 사용하여 플로를 렌더링할 수 있습니다. 섹션을 사용하면 플로 화면에서 원하는 수만큼 최대 4개의 열과 섹션을 추가할 수 있습니다. 구성 요소는 화면 너비에도 반응하므로 더 작은 화면에서 작동할 수 있습니다. 마지막으로 전체 섹션에 조건부 가시성을 적용하여 섹션 내의 여러 필드에 더 쉽게 가시성을 대량으로 적용할 수 있습니다. 플로 섹션은 열 머리글도 지원하며 사용자가 레이블을 클릭하여 전체 섹션을 축소할 수 있는 아코디언과 유사한 환경을 제공합니다.

OmniScript는 필드 및 데이터를 표시하기 위한 다양한 레이아웃 옵션을 제공합니다. 조건부로 축소 가능한 아코디언을 포함하여 최대 12개의 열로 데이터 섹션을 만들 수 있습니다.

LWC를 사용하면 Lightningedit|view] 형식 및 지원되는 Lightning] 필드를 사용하여 레이아웃을 제어할 수 있습니다. 레이아웃 제한은 HTML/CSS에서만 적용됩니다. Lightning 연결된 페이지 레이아웃의 섹션 구성을 준수합니다. 예를 들어, 섹션이 페이지 레이아웃에서 2열인 경우 이 구성 요소의 2열입니다.

다른 지역의 사용자 또는 다른 언어를 사용하는 사용자가 양식에 액세스할 수 있는 경우 구축하는 데 사용하는 도구가 현지화 요구 사항을 충족하는지 확인해야 합니다. 추가 지침 및 권장 사항은 Salesforce Well-Architected - Localization을 참조하십시오. 특히 양식의 경우 현지화 요구 사항은 일반적으로 텍스트 요소를 다른 언어로 번역하는 작업을 수행합니다.

• 양식을 두 개 이상의 국가 또는 지역에서 사용합니까?
• 양식의 텍스트를 다른 언어로 현지화해야 합니까?

사용자 정의 필드를 현지화한 경우 동적 양식에서 번역된 레이블이 적용됩니다. 동적 양식은 Lightning 앱 빌더에서 구성 요소 레이블 및 특성에 할당한 사용자 정의 레이블도 반영합니다.

플로는 번역 워크벤치의 기능을 통해 모든 표준 및 사용자 정의 화면 구성 요소에 대한 사용자 대면 레이블 번역을 지원합니다. 다음 화면 구성 요소의 레이블, 도움말 텍스트, 오류 메시지를 현지화할 수 있습니다. 텍스트, 긴 텍스트 영역, 숫자, 통화, 확인란, 라디오 버튼, 선택 목록, 다중 선택 선택 목록, 확인란 그룹, 암호, 날짜, 날짜/시간.

이메일 보내기 또는 Chatter 게시와 같은 기본 작업에 대한 번역 지원이 내장되어 있지 않습니다. 그러나 해결 방법이 있습니다. 번역된 레이블을 사용자 정의 레이블으로 정의하는 경우 Flow Builder에서 해당 레이블을 구성할 때 작업 또는 구성 요소에서 해당 사용자 정의 레이블을 참조할 수 있습니다. 사용자 정의 레이블을 참조하는 플로 수식을 만들고 플로의 적절한 위치에서 해당 수식을 참조합니다.

OmniScript는 번역에 사용자 정의 레이블을 사용합니다. Omniscripts 다국어를 준비하려면 이 도움말 문서을 참조하십시오.

이제 LWC입니다. 특정 기본 구성 요소는 번역 워크벤치(예: Lightning 구성된 경우 관련 개체의 필드, 도움말 텍스트, 확인 메시지 번역을 자동으로 상속합니다.

코드에 새 번역 가능한 레이블을 도입해야 할 경우 사용자 정의 레이블은 계속해서 히어로입니다. 필요한 사용자 정의 레이블을 선언한 다음 @salesforce/label 범위 모듈에서 구성 요소로 가져옵니다.

사용 가능한 몇 가지 종단간 테스트 자동화 도구(예: Selenium)를 사용하여 사용자가 양식과 상호 작용하는 방식을 시뮬레이션할 수 있습니다. Lightning 페이지 및 화면 플로를 포함하여 표준 또는 사용자 정의 UI에 대해 이러한 테스트를 작성할 수 있습니다. 그러나 이러한 유형의 테스트는 수행 중인 각 메서드의 출력을 확인할 수 없습니다. UI 테스트 자동화 요구 사항을 고려할 때 이 사항을 고려하십시오.

• 양식에 대한 자동 테스트가 필요합니까?
• 수행해야 하는 테스트 유형은 무엇입니까?
• 테스트 자동화에 필요한 세분화 수준은 어느 정도입니까?

UI 테스트 자동화 요구 사항을 고려하십시오.

업계 표준 CI/CD 시스템 및 도구와 함께 작동하는 보다 세분화된 자동화 및 검증을 가능하게 하는 유닛 테스트는 구성 요소 비즈니스 논리, JavaScript 컨트롤러 및 출력을 테스트할 수 있습니다. 하위 코드만 사용하면 테스트를 자체 작성할 수 없지만 Salesforce는 포괄적인 솔루션을 엄격하게 테스트합니다.

구성 요소의 메서드가 충분히 복잡하여 개별적으로 테스트하려는 경우 메서드를 전용 JavaScript 파일에 넣습니다. 그런 식으로, 당신은 그들을 LWC로 가져올 수 있습니다 그리고 import { sort } from 'c/utils';와 같은 Jest 테스트.

Salesforce에서 엔드 투 엔드 자동화를 구축하는 다양한 옵션을 비교하려면 UI 테스트 자동화를 참조하십시오. ISV의 코드 없는 솔루션을 사용하거나, Build Your Own 맞춤형 테스트 자동화 솔루션을 사용하거나, Selenium WebDriver 또는 WebdriverIO와 같은 오픈 소스 테스트 프레임워크를 사용하는 경우에 대한 고려 사항이 포함됩니다. 이러한 솔루션은 Lightning 페이지의 동적 양식, 유틸리티 막대의 화면 플로 또는 빠른 작업 플로의 LWC 등 Salesforce의 모든 UI 상호 작용에 유효합니다.

프로덕션 환경에 양식을 배포한 후에는 양식이 효과적으로 사용되고 있는지 확인하려고 합니다. 사용 사례에 따라 정보가 작성된 횟수를 추적하는 것에서 정보를 제출하기 전에 사용자가 입력하는 데 소요되는 시간까지 모든 것을 의미할 수 있습니다. 도구를 선택하기 전에 추적할 KPI를 식별해야 합니다.

• 양식 사용을 추적해야 합니까?
• 양식이 효과적으로 사용되고 있는지 여부를 결정하는 KPI는 무엇입니까?

양식의 전반적인 사용 및 채택을 추적해야 하는 경우 하위 코드 도구로 시작합니다. 동적 양식과 화면 플로는 모두 즉시 사용 가능한 사용자 정의 보고서 유형을 사용하여 추적할 수 있지만 화면 플로 추적 보고서에서 더 세분화할 수 있습니다. LWC 사용을 추적해야 하는 경우 해당 LWC를 사용하는 위치에 따라 기본 가용성이 결정됩니다. Lightning 페이지에 있는 경우 Lightning 페이지 사용량을 추적할 수 있는 항목이 LWC에 적용됩니다. 플로에 포함된 LWC에도 동일한 사례가 적용됩니다.

동적 양식 자체는 기본으로 추적할 수 없지만, Lightning 사용 개체를 통해 상위 Lightning 페이지의 사용을 추적할 수 있습니다. 표준 Lightning 페이지를 추적하려면 페이지 메트릭별 Lightning 사용자 사용자 정의 보고서 유형을 사용합니다. 사용자 정의 Lightning 페이지에서 동일한 경우 FlexiPage 메트릭별 Lightning 사용이 있는 사용자 사용자 사용자 정의 보고서 유형을 사용합니다.

플로에서 특정 양식의 채택을 추적할 수 있습니다(그것이 있는 페이지뿐만 아니라). "샘플 플로 보고서: 화면 플로" - 다음과 같은 질문에 답변합니다.

• 이 양식의 완료율은 얼마입니까? 제대로 채택되었습니까?
• 사용자가 이 양식을 작성하는 데 시간이 얼마나 걸립니까?
• 사용자가 가장 많은 시간을 사용하는 화면은 무엇입니까?
• 사용자는 얼마나 자주 뒤로 이동합니까?
• 오류는 얼마나 자주 발생합니까?

표준 보고서가 요구 사항을 충족하지 않는 경우 해당 보고서를 복제하여 자체적으로 변경하거나 스크린 플로 보고서 유형을 사용하여 처음부터 Build Your Own을 만듭니다.

패키지 기반 Omniscript 런타임을 사용하는 경우 Vlocity용 OmniStudio 추적 서비스를 사용할 수 있습니다. 이 서비스는 모든 유형의 이벤트를 추적합니다. 예를 들어 Omniscript에서 단계를 완료하는 데 소요되는 시간을 추적하여 프로세스 개선 사항을 식별할 수 있습니다. 표준 OmniStudio에서 이 서비스를 지원하는 OmniStudio 팀의 로드맵에 명시되어 있습니다.

화면 플로, Omniscript 또는 Lightning 페이지에 포함되지 않은 LWC에 대해 동일한 내용을 추적하려면 기본 제공 옵션이 없습니다. Apex 사용하여 사용자 정의 솔루션을 구축할 수 있습니다.

솔루션을 테스트 또는 프로덕션에 배포하기 위해 상위 환경에 배포해야 하는 경우 변경 집합 또는 DevOps Center 사용하여 배포할 수 있습니다. 동적 양식, 플로, LWC는 해당 배포 옵션에서 완전히 지원됩니다. OmniStudio에는 별도의 도구가 필요합니다. IDX 워크벤치.

• 양식을 배포할 계획은 무엇입니까?
• 양식을 둘 이상의 Salesforce 조직에 배포합니까?

ISV 또는 AppExchange 배포를 위해 솔루션을 패키징하려는 파트너인 경우 먼저 동적 양식, 플로, LWC를 살펴보는 것이 좋습니다. OmniStudio는 패키징을 지원하지 않습니다.

이 가이드는 동적 양식, 화면 플로, OmniStudio, LWC를 통해 가능한 기능 및 사용자 정의 수준을 이해하는 데 도움이 되는 것입니다. 상위 수준:

• LWC는 양식을 만드는 데 가장 사용자 정의 가능하고 강력한 옵션이지만, 가드 레일이 가장 적습니다. 보안 및 확장성을 보장하는 방식으로 구성 요소를 구축하는 것은 귀하에게 달려 있습니다.
• 동적 양식은 가장 유연하지 않지만, 오류가 발생할 가능성이 훨씬 적습니다.
• 플로 및 OmniStudio는 동적 양식보다 강력하지만 LWC 수준에서는 강력하지 않습니다. 동일한 토큰으로 동적 양식보다 가드 레일이 더 적지만 사용자 정의 코드보다 깨지기가 더 어렵습니다.

여러 도구가 요금에 맞는 경우 팀에 적합한 도구를 결정합니다. 다른 아키텍트 의사 결정 가이드에서는 해당 결정을 내릴 때 고려해야 할 추가적인 측면을 소개합니다.

여기에서는 각각의 측면에 대한 세부 사항을 살펴보지 않지만 이 문서에서 평가하는 특정 도구에 대해 해당 측면을 해석해야 합니다.

특수 기술: 비교 중인 도구에 대한 팀의 전문 지식은 어느 정도입니까? LWC 또는 JavaScript에 익숙하고 숙지된 작성자는 몇 명입니까? Flow Builder 전문가이거나 손가락 세로 탐색에 관심을 보인 작성자는 어떨까요? 일반적으로 동적 양식 및 플로 기술은 양식을 작성하는 사람들의 더 많은 집단에 대해 더 잘 사용할 수 있습니다. 동적 양식은 가장 선언적 양식 작성 도구이며 플로보다 항상 쉽게 학습할 수 있습니다. 그러나 플로 팀은 이 막대를 최대한 낮춰야 합니다. 복잡성 측면에서 OmniStudio는 플로와 LWC 사이에 위치하며 상당한 양식 구축 능력을 제공합니다.

제공 위임: 일부 요구 사항이 LWC를 호출하더라도 전체 솔루션을 LWC로 구축해야 하는 것은 아닙니다. LWC가 필요한 부품과 하위 코드 솔루션에 구축되지 않은 부품이 코딩되도록 솔루션을 모듈 방식으로 구축하는 방법을 고려합니다. 이를 수행하면 다양한 팀의 효율성을 극대화하고 각 개인이 전문 분야에 적합한 문제를 해결할 수 있습니다.

이제 플로 및 LWC에 대해 살펴보겠습니다. 반응형 화면 구성 요소를 사용하면 화면 플로 구성 요소가 동일한 화면에서 서로 대화하여 설계자, 관리자, 개발자를 위한 완전히 새로운 도구 상자를 확보할 수 있습니다. 개발자는 이제 조직 전체에서 재사용할 수 있는 용도에 맞는 모듈식 구성 요소를 만들 수 있으므로 팀원 모두의 생산성을 높일 수 있습니다. 개발자는 표준 및 사용자 정의 플로 구성 요소의 혼합을 사용하여 새로운 문제 해결에 집중하고 시간을 절약하여 양식의 역동성을 달성할 수 있습니다. 플로의 반응형 구성 요소를 사용하면 양식을 작성할 때 플로와 LWC를 혼합하는 것이 가장 적합한 시기가 되었습니다.

기존성 및 장기 소유권: 다단계 양식이 있는 경우 플로 또는 플로와 LWC의 혼합으로 시작하는 것이 좋습니다. 솔루션을 유지 관리하는 하위 코드 팀이 있는 경우 해당 대상 그룹에 대해 가능한 한 솔루션을 구성하고 확장할 수 있는 방법을 생각해 보십시오. 선택한 도구에 상관없이 솔루션을 복합 가능한 단위로 구성하여 유지 보수 및 안정성을 향상합니다.

앞으로 레코드 세부 사항 페이지를 구성하는 것이 좋습니다. Lightning 앱 빌더에서 Lightning 페이지를 사용하는 동적 양식입니다. 고급 페이지 레이아웃이 출시된 지 오래되었으며 해당 추세는 계속됩니다. 다음은 이유입니다.

• 동적 양식은 보다 유연합니다. Lightning 앱 빌더에서 원하는 곳에 필드와 섹션을 배치하여 섹션, 탭 및 아코디언을 활용할 수 있습니다. Lightning 페이지의 구성 요소와 마찬가지로 여러 페이지 레이아웃이나 레코드 유형을 정의하지 않고도 필드 및 섹션의 가시성을 제어할 수 있습니다.
• 아코디언 및 탭 구성 요소를 사용하면 처음에 표시되는 필드의 양을 제한할 수 있습니다. 무슨 뜻인지 예측해 보세요? 페이지 로드 시간을 단축합니다.
• Lightning 페이지의 레이아웃 관리는 Lightning 앱 빌더에서 페이지에 대한 모든 내용을 관리할 수 있으므로 페이지의 내용이나 페이지에 액세스할 수 있는 사용자에 상관없이 간단합니다. 더 이상 Lightning 페이지를 변경하기 위해 페이지 레이아웃을 업데이트할 필요가 없습니다. 가시성 규칙의 강력한 기능을 사용하면 더 이상 여러 페이지(또는 페이지 레이아웃)를 만들어 언제 어떤 필드를 볼 수 있는 사람을 제어할 필요가 없습니다. 또한 사용자에게 Lightning 페이지와 페이지 레이아웃을 모두 할당하는 대신 Lightning 페이지만 할당해야 합니다.

가능한 경우 동적 양식을 사용하고 필요한 경우에만 페이지 레이아웃으로 돌아가는 것이 좋습니다. Idea Exchange에서는 항상 귀사에 가장 큰 영향을 미치는 개선 사항에 대한 피드백을 환영합니다.

동적 양식, 화면 플로, OmniStudio, LWC와 관련된 모든 성능 고려 사항은 해당 기술 자체의 프레임워크에 중점을 둡니다. LWC에 기반하는 항목(LWC 외에도 물론)은 Aura에 기반하는 항목보다 성능이 뛰어납니다. LWC 프레임워크는 프레임워크 추상화를 통해 JavaScript가 아닌 웹 엔진에서 기본적으로 핵심 기능이 구현되므로 더 나은 성능을 제공합니다. 익숙하지 않은 경우, 이 블로그 게시물을 읽어 주십시오.

2019년에는 Aura와 LWC의 동일한 기능의 성능을 비교하는 사례 연구를 실시했습니다. DreamHouse를 Aura에서 LWC로 변환한 결과 개발 환경이 현재의 웹 프런트엔드 개발 표준 및 패턴에 훨씬 더 부합했을 뿐만 아니라 성능 향상도 크게 향상되었습니다. 실험실 측정은 콜드 캐시의 경우 2.4%~24.7%, 핫 캐시의 경우 같은 두 페이지의 경우 **31.83%~****63.32%**의 이점을 보여주었습니다.

이제 양식 기술이 사용하는 프레임워크는 무엇입니까? 다시 말해, 이러한 우수한 성능으로 인한 혜택은 무엇입니까?

• Lightning 페이지 메타데이터에 통합된 동적 양식은 LWC 스택을 사용하는 기초에 구축되므로 오랫동안 요청한 기능을 구현할 수 있습니다. 동적 양식은 성능 보너스로 프로그레시브 렌더링을 사용하므로 필드 수가 많은 페이지의 페이지 로드 시간이 향상됩니다.
• 화면 플로는 대부분의 기본 개별 구성 요소가 이제 LWC로 변환되어 LWC에 구축되며, 다음 두 가지 기본 구성 요소는 제외됩니다. 파일 업로드 및 이미지 플로 팀이 플로 런타임 클라이언트를 LWC 및 대부분의 구성 요소로 변환했지만, 고객은 Aura 화면 구성 요소를 LWC로 변환해야 합니다. 뿐만 아니라 Salesforce는 화면 플로의 새로운 반응형 구성 요소 프레임워크에서 LWC 구성 요소만 지원합니다. 이 작업을 수행하는 방법을 설명하는 훌륭한 Trailhead 모듈이 있습니다. Aura 개발자를 위한 Lightning 웹 구성 요소. 즉, 화면 플로 또는 기타 컨테이너에 대한 사용자 정의 구성 요소를 구축하려는 경우 항상 LWC로 이동하십시오.
• 몇 가지 버전의 OmniStudio를 사용할 수 있습니다. 장기 고객인 경우 Angular를 사용하고 있을 수 있습니다. 모든 신규 고객은 LWC 기반 Omniscript 및 FlexCard를 사용하여 시작하고 기존 고객은 Angular에서 마이그레이션하는 것이 좋습니다.
• LWC는 ...에 구축되었습니다. 물론 LWC입니다. 프리베이입니다.

설계자는 사용 가능한 모든 옵션 및 특정 사용 사례에 적용할 수 있는 방법을 철저하게 이해해야 합니다. Salesforce에서 양식을 작성하려면 하위 코드(Lightning 앱 빌더에서 동적 양식 사용, Flow Builder에서 화면 플로, Omniscripts에서 OmniStudio)에서 프로 코드(LWC 프레임워크 사용)에 이르기까지 다양한 옵션을 사용할 수 있으며, 중간에 화면 플로 또는 Omniscripts 및 LWC가 조합되어 있습니다. 이 가이드에 유의하고 Salesforce에서 양식을 작성하거나 재설계할 계획인 경우 참조로 사용하십시오. 간소화되고 유용한 양식을 설계하는 방법에 대한 지침을 찾고 있다면 Salesforce Well-Architected: 참여하고 있어요.

귀하에게 가장 적합한 내용을 게시하도록 도와주십시오. 이 콘텐츠에 대한 피드백을 받으려면 설문 조사를 진행하고 다음에 원하는 내용을 알려주십시오.