건물 양식

Agentforce 360 플랫폼에서는 로우코드부터 프로 코드 접근 방식에 이르기까지 양식을 작성할 수 있는 여러 가지 옵션이 있습니다. 한쪽 끝에서는 Lightning 앱 빌더의 동적 양식과 Flow Builder의 화면 플로우를 로우코드 솔루션으로 사용할 수 있습니다. 반면에 Lightning Web Component(LWC) 프레임워크는 프로 코드 솔루션에 사용됩니다. 연속 범위 내에서, LWC로 확장된 화면 플로우와 Omnistudio로 구축된 고객용 양식을 활용하여 여러 가지 방식으로 도구를 조합할 수 있습니다.

이 가이드는 UI 솔루션 양식 작성에 대한 결정 프레임워크 및 지침을 제공합니다. 특히 12개의 런타임 및 비기능적 결정 지점을 사용하여 주어진 사용 사례에 가장 적합한 기술을 적절하게 선택합니다.

• Lightning 페이지에 대한 만들기/편집/보기 레이아웃을 작성할 때 동적 양식을 사용하십시오. 앞으로 _Lightning 앱 빌더_에서 _동적 양식_을 사용하여 레코드 세부 사항 페이지를 구성하는 것이 좋습니다.

• 한 개체에 대한 양식을 작성, 생성 또는 편집해야 하는 경우 Lightning 페이지 및 _동적 양식_을 사용합니다. Agentforce 360 플랫폼에서 양식을 작성하는 가장 쉬운 방법입니다. 또한 추가 기능(예: 필드 가시성 제어)을 제공합니다.

• 다중 페이지 양식 또는 마법사를 작성하고 있으며 엄격한 UX 또는 브랜딩 요구 사항이 없는 경우 화면 플로를 사용하십시오. 화면 플로는 여러 양식을 오케스트레이션할 수 있는 선형 탐색 프레임워크를 제공합니다. LWC를 사용해 양식 간 탐색을 위한 자체 프레임워크를 구성할 수도 있지만, 양식 상태에 집착하기보다 양식 자체에 집중할 수 있도록 플로우에 작업을 맡기는 것을 권장합니다.

• 양식을 지원하는 추가 논리 또는 작업이 필요한 경우, 스크린 플로우, Omnistudio 또는 LWCs를 사용하십시오. 이러한 각 도구는 단일 레코드 만들기 또는 편집 이상으로 솔루션을 확장할 수 있도록 하여 솔루션을 향상할 수 있는 다양한 방법을 제공합니다. 이 경우 더 많은 용어는 고급 논리(예: 분기 또는 반복)를 참조하거나 외부 시스템과 통합, 이메일 보내기 또는 사용자의 모바일 앱에 알림 푸시와 같은 작업을 참조할 수 있습니다.

• 고급 UX 요구 사항이 있거나 UI 가시성 이상을 동적으로 관리해야 하는 경우 LWC 또는 Omniscript를 사용하십시오. 테마 및 열 기반 레이아웃을 사용하여 충족할 수 있는 요구 사항의 경우 로우코드 빌더에서 직접 양식을 작성할 수 있습니다. 그러나 양식의 스타일을 세부적으로 제어하려면 LWC의 유연성이 필요합니다. 산업 고객인 픽셀 퍼펙트 브랜딩이 필요하거나 복잡한 계층 데이터가 있는 경우 Omnistudio를 사용하여 복잡한 비즈니스 논리 및 데이터 변환을 처리할 수 있는 소비자급 양식을 구축할 수 있습니다.

• 테스트 자동화를 배포해야 하는 경우 LWC를 사용하십시오. 포함할 위치와 상관없이 LWC에 대한 단위 테스트를 작성할 수 있습니다. 이를 통해 더 강력한 테스트 전략을 만들 수 있습니다. 여기에는 여러 레코드가 있는 대량 테스트와 음수 테스트가 포함될 수 있습니다.

• “양자택일” 결정에 얽매이지 않습니다. 여러 옵션을 결합하여 사용 사례에 가장 적합한 솔루션을 찾을 수 있습니다(예: 플로의 내장형 탐색 시스템 및 LWC에서 제공하는 전체 스타일 지정 유연성이 필요한 경우 함께 사용할 수 있음).

다음 도구는 일반적으로 양식 환경을 구현하고 확장하는 데 사용됩니다.

이 표는 Salesforce를 통해 양식을 작성하는 데 사용할 수 있는 도구와 필수 기술 및 라이센스 고려 사항을 간략하게 보여줍니다.

참고: 각 도구에 대해 지원되는 특정 기능, 클릭 기반 도구와 코드 기반 도구 간에 선택하는 방법, 나중에 섹션에서 결합할 시기를 자세히 살펴보겠습니다.

제품 및 도구를 선택할 때 유의해야 할 몇 가지 결정 사항이 있습니다. 이 표는 다양한 결정 지점을 간략하게 보여주며 상위 수준 지침을 제공합니다.

참고: 후속 결정 비교 테이블에는 도구-기능 쌍과 연결된 몇 가지 값이 있습니다.

• 사용 가능: 도구/기능은 기본 고려 사항에 따라 작동합니다.

• 사용 불가: 향후 12개월 이내에 지원을 추가할 계획이 없습니다.

• 이상적이지 않음: 이 도구/기능은 작동할 수 있지만 최적의 도구는 아닙니다.

• 해당 안 함: 이 도구는 특정 사용 사례에 적용되지 않습니다.

다음 시나리오를 사용하여 범위, UX, 운영 요구 사항을 기준으로 도구 선택을 비교합니다.

단일 화면 양식에서 모든 사용자 입력을 가져올 수 있는 경우 동적 양식부터 시작합니다. 레코드 페이지의 동적 양식은 단계화된 비즈니스 프로세스를 지원하기 위해 경로 기능을 사용할 수 있다는 점에 유의하십시오.

• 단일 화면이 필요합니까? 과업을 완료하려면 사용자가 여러 화면 사이를 탐색해야 합니까?

• 사용자가 양식을 작성할 때 프로세스 진행 상황을 시각적으로 보여주도록 하시겠습니까? 사용자가 각 화면의 정보를 특정 순서로 작성해야 하거나 필요에 따라 화면 간에 앞뒤로 이동할 수 있어야 합니까?

동적 양식에서 제공하는 것보다 더 많은 기능이 필요한 경우 몇 가지 추가 질문에 따라 플로, Omnistudio, LWC 중에서 선택할 수 있습니다.

• 양식 하단에 내비게이션 바를 표시해도 괜찮습니까? 스크린 플로우와 OmniScript 탐색 환경이 바람직하지 않은 사용자 경험을 제공한다면, LWC를 고려하십시오.

• 양식 뒤에 수행해야 하는 작업은 무엇입니까? 관리자가 동작을 구성할 수 있어야 하는 경우 플로를 사용합니다. 복잡한 다중 개체 관계의 경우 Omniscript 또는 _LWC_를 사용하십시오.

플로 또는 Omnistudio를 선택하는 경우 올바른 UX를 달성하기 위해 LWC를 구축해야 할 수도 있습니다. 양식의 스타일을 올바르게 지정하기 위해 LWC를 이미 구축하는 경우 플로에 해당 구성 요소를 포함해야 하는지 고려하십시오.

마법사 스타일의 탐색

반면, 솔루션이 마법사처럼 보여 사용자가 여러 화면 사이를 탐색해야 한다면 플로 또는 Omnistudio를 고려하십시오. 플로 및 Omnistudio는 내장된 탐색 모델을 사용하므로 함께 연결된 LWC를 구축하고 유지할 필요가 없습니다. 탐색은 선형이며 앞으로 이동하는 작업, 뒤로 이동하는 작업 및 나중에 양식을 저장할 수 있는 메커니즘이 있습니다. 목적에 맞는 경우 비선형 탐색을 사용하여 양식을 작성할 수도 있습니다.

Omnistudio는 양식 내에 단계를 표시하는 표준 탐색의 진행률 표시기를 제공하여 주요 탐색 이점을 제공합니다. 단계 보기에 사용자가 다단계 양식에 있는 위치가 자동으로 표시됩니다. 플로와 달리 사용자는 양식 전체에서 다양한 단계를 클릭하여 화면 간에 이동할 수 있습니다.

단일 화면 또는 다중 화면 양식을 작성하는 경우 사용자가 쉽게 탐색할 수 있도록 양식을 간소화해야 합니다.

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

• 사용자가 데스크톱, 모바일 또는 둘 모두를 통해 양식에 액세스해야 합니까?

• 사용자가 유틸리티 막대를 통해 앱의 모든 위치에서 양식에 액세스할 수 있어야 합니까?

• 사용자가 현재 있는 페이지를 떠나지 않고도 양식을 작성할 수 있도록 빠른 작업을 활성화하시겠습니까?

• 외부 웹 사이트에서 양식을 사용할 수 있어야 합니까?

레코드 컨텍스트가 필요하므로 동적 양식 기능은 Lightning 레코드 페이지에서만 지원됩니다. 그러나 Experience Cloud 페이지에서는 동적 양식이 지원되지 않습니다.

레코드 컨텍스트가 필요한 플로우 또는 전역적으로 작동하는 플로우를 구축할 수 있습니다. 다시 말해 다양한 위치에 플로우를 포함할 수 있습니다. 레코드 컨텍스트 플로우의 경우 위치에 다음이 포함될 수 있습니다. Lightning 레코드 페이지, Experience Cloud 레코드 페이지, 개체별 작업 또는 작업 및 권장 사항 배포 전역 플로의 경우, 위치에는 유틸리티 바, 다른 Lightning 또는 Experience Builder 페이지, Snap-ins, 또는 외부 애플리케이션이 포함될 수 있습니다. 현재 플로는 전역 작업으로 지원되지 않지만, 해결 방법으로 Aura 구성 요소에 플로를 래핑할 수 있습니다.

Omnistudio를 사용하면 구성 가능한 FlexCard 및 Omniscripts를 구축할 수 있으며, 플로를 배치할 수 있는 거의 모든 위치에 배치할 수 있지만, 구성 가능한 경우에는 패키지화할 수 없습니다.

LWC는 Salesforce, 커뮤니티, 오픈 소스 프로젝트 전반에서 메타데이터를 통해 대상과 연결할 수 있는 구성 요소를 만드는 데 높은 수준의 재사용성을 제공합니다. LWC 구성 요소는 Lightning Out 2.0을 사용하여 자체 웹사이트에 포함할 수도 있습니다.

LWC 구성 요소는 Lightning-Flow 구성 요소를 사용하여 플로를 시작할 수도 있습니다.

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

현재 이 가이드에 포함된 양식 기술은 Mobile SDK 템플릿에서 공식적으로 지원되지 않습니다. Mobile SDK가 사용 사례에 필수적인 경우 양식을 기본적으로 모바일 응용 프로그램에 구축하거나 Visualforce 페이지를 구축하는 것이 좋으며 양식 요소를 염두에 두는 것이 좋습니다.

동적 양식은 양식에서 값을 사용하여 레코드를 만들거나 업데이트해야 하는 경우에 적합합니다. 결정 또는 반복 레이어 만들기 또는 양식의 입력을 사용하여 Slack 게시물 또는 이메일을 생성하는 등 해당 범위를 벗어나는 기능에 대해 플로, Omnistudio 또는 LWC를 활용해야 합니다.

• 백그라운드에서 수행해야 하는 작업 또는 논리는 무엇입니까?

• 관련 레코드의 값을 사용해야 합니까?

• 단일 트랜잭션 또는 여러 트랜잭션에서 양식의 작업을 완료해야 합니까?

• 외부 시스템과 통합해야 합니까?

• 재사용 가능성 및 모듈성에 대한 요구 사항은 무엇입니까?

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

Omnistudio는 통합 절차와 데이터 매퍼를 사용하여 Salesforce 내부와 외부의 데이터를 가져오고 변환합니다. 수많은 코드 없는 기능 덕분에 다양한 수준의 관계를 가진 데이터 집합을 평탄화하고 확장하는 데 뛰어납니다.

플로, Omnistudio, LWC는 모두 Apex 통합되므로 선택한 솔루션 내에서 간편하게 공백을 닫을 수 있습니다(예: LWC에서 레코드를 필터링해야 하는 경우 Apex 유선 어댑터를 사용하여 복잡한 SOQL 쿼리를 만들 수 있습니다). 클릭 기반 스토리로 인한 영향을 받는 경우 서버 측의 요구에 맞게 Apex 컨트롤러를 대체하는 실용적인 대안으로 Flow 또는 Omnistudio를 사용하는 것이 좋습니다.

또한 작업을 즉시 커밋할 것인지 또는 작업을 양식의 특정 부분으로 연기할 것인지 고려해야 합니다. 이는 다중 페이지 양식을 사용하는 경우 특히 유용합니다. Flow를 사용하면 여러 양식(Flow 화면)의 입력을 쉽게 결합하고, 나중에 마법사(Flow)에서 이를 사용하여 특정 작업을 수행할 수 있습니다. 이것이 바로 Flow를 설계할 때 권장하는 방식입니다. 마지막 단계에서 작업을 수행합니다(사용자가 답변을 변경하기 위해 화면 간에 왔다 갔다 할 경우).

트랜잭션 및 관리자 제한은 Agentforce 360 플랫폼의 일부입니다. 사용 사례가 상당히 간단한 경우 특정 작업이 발생하는 트랜잭션을 제어하는 것이 중요하지 않을 수 있습니다. 그러나 여러 작업을 여러 트랜잭션에서 수행하는 대신 여러 작업을 하나의 트랜잭션에 결합하려는 몇 가지 사용 사례가 있습니다.

다음은 몇 가지 예시입니다.

• 롤백: 양식이 백그라운드에서 여러 레코드를 생성한다고 가정합니다. 세 번째 레코드 생성에 실패할 경우 처음 두 개의 레코드를 롤백해야 합니까? 각 작업이 서로 독립적인 경우 별도의 트랜잭션으로 실행할 수 있습니다. 그러나 서로 종속되어 있으며 하나의 실패로 다른 하나도 롤백되도록 하려는 경우 단일 트랜잭션으로 구현해야 합니다. 양식이 Flow에 있는 경우 오류 경로의 롤백 요소를 사용하여 트랜잭션을 롤백하고 데이터 무결성을 보장할 수 있습니다.

• 거버너 제한에 대한 다운스트림 영향: 양식에서 레코드를 만들거나 업데이트할 때 해당 작업의 다운스트림 영향을 고려해야 합니다.

  • 제안된 레코드 변경 사항을 기반으로 저장 순서 내의 어떤 프로세스, 워크플로 규칙, Flow 트리거, Apex 트리거 또는 기타 항목이 실행될 수 있습니까?

  • 이러한 집합 변경 사항은 해당 트랜잭션 내에서 소비되는 거버너 제한에 어떤 영향을 미칩니까?

  • 특정 레코드 변경으로 인해 제한에 영향을 미치는 많은 다운스트림 변경 사항이 발생할 수 있는 경우 자체 트랜잭션 내에서 해당 레코드 변경 사항을 분리하는 것이 가장 좋습니다.

• 배치 처리: 여러 업데이트를 함께 배치해야 할 수도 있습니다 (UI 컨텍스트 내에서도). 다중 화면 양식이 대규모 레코드 그룹을 대상으로 반복 처리되는 경우, 각 화면 이후에 레코드 업데이트를 커밋하는 대신 모든 레코드에 대한 업데이트를 수집할 때까지 기다린 다음, 모든 레코드를 업데이트하기 위한 하나의 요청을 제출합니다.

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

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

1. 최종 사용자가 화면과 상호 작용한 다음, 다음을 클릭합니다.

2. 클라이언트가 API에 입력 요청을 게시합니다.

3. API가 요청을 수신하고 트랜잭션 및 데이터베이스 연결을 엽니다. 그런 다음, API는 플로 엔진을 호출하여 요청을 처리합니다.

4. Flow 엔진이 제어를 넘겨받아 Flow 정의의 적절한 경로를 따라 진행하다가 화면 또는 로컬 작업 노드에 도달하면 멈춥니다. 그런 다음, 엔진이 해당 노드에 대한 정보를 API에 반환합니다.

5. API가 렌더링할 다음 화면의 세부 사항을 포함하는 응답 개체를 만들고 클라이언트에게 해당 개체를 반환합니다. 이 시점에서 데이터베이스 변경이 커밋되고(저장 주문 실행) 데이터베이스 연결 및 트랜잭션이 종료됩니다.

6. 클라이언트가 API 응답을 사용하여 사용자가 상호 작용하는 다음 화면을 렌더링합니다.

7. 1단계에서 시작하고 프로세스를 반복합니다.

즉, 화면은 트랜잭션을 끊습니다. 이러한 경우 보류 중인 작업 또는 DML이 커밋되고 이전 트랜잭션이 마감되고 새 트랜잭션이 시작됩니다. 특정 설계 요소(지정된 트랜잭션으로 그룹화하는 작업)는 사용자가 결정한다는 점에 유의하십시오.

다음은 몇 가지 예시입니다.

• 시작하면 여러 화면에서 입력을 수집한 다음, 하나의 트랜잭션 내에서 여러 작업을 수행하는 플로가 표시됩니다.
• 다음 Flow는 별도의 트랜잭션에서 각 작업을 수행합니다.
• Flow는 Roll Back Records 요소를 사용하여, 일련의 데이터베이스 작업 중 단일 작업이 실패할 경우 전체 트랜잭션을 롤백할 수 있도록 합니다. 레코드를 생성하고, 레코드를 업데이트한 다음, 추가 레코드를 생성하는 플로가 있다고 가정합니다(다음 플로에 표시).

이 시나리오에서 처음 두 요소가 성공하고 마지막 요소가 실패하면, 처음 두 DML 작업은 계속해서 적절한 레코드를 생성하고 업데이트하지만, 세 번째 작업은 실패합니다. 레코드 롤백 요소를 사용하면 세 가지 작업을 모두 함께 수행해야 하는 경우(최종 Flow에 표시된 것처럼) 전체 트랜잭션이 롤백되는지 확인할 수 있습니다.

참고: 자세한 내용은 트랜잭션 플로 및 트랜잭션 플로 대량 처리을 참조하십시오.

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

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

• 각 UI API 호출은 자체 트랜잭션 내에서 분리됩니다.

• 단일 트랜잭션 내에서 여러 작업을 수행해야 하는 경우 입력 내용을 서버측 기술(예: Apex 컨트롤러 또는 플로)로 보냅니다. 해당 기술에 대한 정기 트랜잭션 규칙이 계속 적용됩니다.

Flow, Omnistudio 및 LWC는 모두 플랫폼 이벤트(이벤트 기반 아키텍처) 및 API 통합을 지원합니다. 사용자 지정 Apex 코드 외에도 Flow 및 Omnistudio에는 API와 통합할 수 있는 선언적 지원 메커니즘이 있습니다.

MuleSoft API 또는 RPA Bot에 연결해야 하는 경우 외부 서비스를 생성하므로 MuleSoft 서비스를 사용하십시오.

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

다른 모든 인스턴스의 경우 플로의 HTTP 콜아웃 기능(외부 서비스에서 제공) 또는 Omnistudio의 HTTP 작업을 사용합니다.

Omnistudio는 데이터 매퍼를 통해 데이터를 변환하기 위해 통합 절차를 사용하여 외부 시스템에 콜아웃할 수 있는 다양한 통합 기능을 제공합니다.

구현을 위해 사용자 정의 Apex 코드 또는 외부 서비스를 사용하든 상관없이 콜아웃은 여전히 콜아웃입니다.

다음은 알아야 할 사항입니다.

• 콜아웃을 처리하는 데 상당한 시간이 걸릴 수 있습니다.

• 콜아웃이 동기식으로 실행되면 데이터베이스 트랜잭션이 열려 있는 동안 수행됩니다.

• 보류 중인 데이터베이스 작업이 있는 경우 Salesforce에서 데이터베이스 트랜잭션을 열어 둘 수 없습니다.

주된 제한 사항은 데이터가 일관되지 않은 상태로 남아 있는 위험입니다. 이는 동일한 트랜잭션 내에서 생성, 업데이트 또는 삭제 작업을 수행한 다음, 콜아웃을 수행할 때 발생합니다. 위에서 언급한 세 번째 고려 사항이 있으므로 이 패턴은 처음 두 가지 고려 사항으로 인해 허용되지 않습니다.

플로에서 트랜잭션을 중단하여 이 제한을 무시할 수 있습니다. 화면 및 로컬 작업이 브라우저 컨텍스트를 다시 도입한다는 점에 유의하십시오. 외부 콜아웃으로 작업할 때 화면 및 로컬 작업을 사용할 수 있지만 호출 가능한 고급 설정에서 트랜잭션 제어를 활성화하는 것이 좋습니다. 트랜잭션 관리를 사용하면 콜아웃을 만들기 전에 트랜잭션을 자동으로 종료할 수 있습니다. 트랜잭션 제어를 활성화하려면 호출된 작업의 고급 섹션에서 “항상 새 트랜잭션 시작”을 선택합니다. LWC는 트랜잭션에 대한 콜아웃의 영향을 간소화하는 데 도움이 됩니다. 즉, Lightning 데이터 서비스(LDS)를 사용하여 데이터 작업을 수행한 다음, Apex 컨트롤러를 사용하여 외부 콜아웃을 수행합니다. LDS 호출은 자체 트랜잭션 내에서 (Apex 콜아웃과 별도로) 분리되므로 결과적으로 데이터 불일치가 발생하지 않도록 보호합니다.

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

여러 구성 요소에서 사용할 수 있는 라이브러리, 유틸리티 및 구성 요소를 작성하는 방식과 마찬가지로 하위 플로의 기능을 활용하여 플로를 만들 때 유사한 디자인 패턴을 적용할 수도 있습니다. 이렇게 하려면 플로를 더 작은 모듈식 버킷에 저장한 다음, 하위 플로 요소를 사용하여 다른 플로에서 호출합니다. 설계에 따라, 하나의 플로우를 독립적으로도, 서브플로우로도 유용하게 만들 수 있습니다.

Omnistudio는 기본적으로 모듈성을 위해 구축되었습니다. Data Mapper, OmniScript, FlexCard, 그리고 Integration Procedure는 모두 독립적으로 구축되지만, 상호 교환적으로도 작동할 수 있습니다. FlexCard는 다른 LWC, Omniscript, 레코드 페이지, Experience Cloud 사이트 내에 포함할 수 있는 LWC 구성 요소로 구축할 수도 있습니다.

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

레코드를 만들거나 업데이트하는 데 사용되는 모든 기술은 기존의 검증 규칙이든 Apex 트리거에 내장된 사용자 정의 검증이든 시스템 수준의 검증을 준수해야 합니다. 레코드 변경을 수행하는 데 사용하는 기술과 상관없이 모든 변경 사항은 저장 주문을 거쳐야 합니다. 즉, 유효성 검사 규칙 외에도 레코드 변경 사항은 여러 저장 전 또는 저장 후 플로우, 저장 전 또는 저장 후 트리거, 에스컬레이션 규칙, 할당 규칙 등을 통해 처리됩니다.

참고: 아직 수행하지 않은 경우 Apex 실행 순서를 검토하고 북마크합니다.

• 시스템 수준 유효성 검사 외에도 양식에 추가 요구 사항이 있습니까?

• 양식 내에서 필수 또는 읽기 전용 필드를 동적으로 설정해야 합니까?

일반적으로 플로 화면 또는 Omniscript 단계의 입력이 바인딩되지 않으므로 양식 자체가 특정 개체와 연결된 시스템 수준 확인을 기본적으로 준수하지 않습니다. 그러나 레코드를 만들거나 업데이트하는 데 사용하는 값은 저장 순서로 처리되므로 개체의 시스템 수준 유효성 검사를 통과합니다.

참고: 일부 화면 플로 구성 요소에서는 입력 유효성 검사를 지원하지 않습니다.

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

플로는 양식 입력 유효성 검사를 유연하게 사용자 정의할 수 있습니다. 클라이언트 수준에서 여러 확인을 수행합니다(예: 누락된 필수 필드 플래그 지정 및 데이터 유형 확인 및 입력 확인 규칙 내 호환 수식). 추가 보안 수준으로 서버에서도 입력 유효성 검사가 평가됩니다. 사용자가 다음을 클릭하면 Flow가 유효성 검사를 위해 다시 서버에 입력을 보냅니다. 잘못된 입력이 반환되면 탐색이 차단되고 적절한 오류가 표시됩니다.

서버는 다음 사항을 확인하여 입력값을 검증합니다.

• 입력의 필수성 설정 또는 입력된 값이 기본 데이터 유형과 호환되는지 여부

• 입력의 사용자 정의 유효성 검사입니다. 부울 수식 식이 충족되지 않을 경우 표시할 오류 메시지를 입력해야 합니다.

• 기본 구성 요소의 사용자 정의 유효성 검사입니다. 플로에 대한 사용자 정의 LWC를 구축하는 경우 validate() 메서드에 자체 확인 코드를 추가해야 합니다.

화면 플로의 메시지 구성 요소를 통해 액세스 가능한 사용자 경고를 제공할 수도 있지만, 이는 사용자가 다른 페이지로 이동하거나 안내 플로의 다음 단계로 진행하는 것을 방지하지 않습니다. 메시지 구성 요소 내의 오류 상태는 탐색이 비활성화될 때 오류 경로를 통해 트리거되는 전용 오류 화면에 가장 적합합니다.

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

LWC의 경우, 대부분의 기본 구성 요소는 자체 클라이언트 측 유효성 검사를 수행합니다(예: lightning-record-form은 시스템 수준의 필수성을 준수하지만, 페이지 수준의 필수성은 준수하지 않습니다). 사용자 정의 구성 요소에 대해 직접 유효성 검사 메커니즘을 구축할 수 있습니다.

사용자가 데이터를 입력해야 하는 필드는 양식의 시작 부분에 표시되어야 합니다. 가능한 경우 양식을 제출하기 전에 클라이언트 측에서 사용자 입력을 확인합니다.

정적 양식이 오래되었습니다. 오늘날 초점은 특정 사용자, 특정 시간, 특정 장소에 적절한 속성 및 값으로 양식을 동적으로 업데이트하는 데 전환되었습니다. Salesforce 양식 작성 도구를 통해 가능한 작업을 자세히 살펴보겠습니다.

• 양식 내에서 동적 응답을 트리거해야 하는 상호 작용 또는 조건 유형은 무엇입니까?

• 양식을 작성하는 동안 화면 외부(백그라운드) 작업을 실행해야 합니까?

• 필드를 보기, 필수, 읽기 전용 또는 비활성화됨으로 설정하거나 양식 입력에 따라 서식을 변경해야 합니까?

반응형 화면은 화면 플로 상호 작용을 활성화합니다. 반응성을 사용하면 화면 플로의 개별 구성 요소가 서로 통신하므로 화면 플로가 더욱 강력해집니다.

오프스크린 데이터 작업 실행

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

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

가시성

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

• 동적 양식은 레코드 필드 값, 조회 필드, 그리고 폼 팩터를 기준으로 가시성을 제어합니다.

• 플로를 사용하면 다른 화면 입력과 플로에서 이전에 채워지는 다른 리소스(예: 다른 레코드의 수식 또는 값)를 기준으로 가시성 규칙을 지정할 수 있습니다.

  • 장치 기반 규칙: 처음부터 명확하지 않을 수도 있지만 사용자가 모바일 장치에 있을 때 특정 필드를 표시하거나 숨기기 위해 수식을 사용할 수 있습니다. $User.UIThemeDisplayed 전역 변수의 값을 확인하는 플로 수식을 작성합니다. 값이 Theme4t인 경우 사용자가 Salesforce 모바일 앱을 사용하여 양식을 작성합니다.

  • 다른 리소스 평가: 수동 변수 및 수식 참조는 서버에서만 평가됩니다. 즉, 해당 리소스가 화면을 처음 렌더링할 때 가진 값은 다른 화면으로 이동할 때까지 유지됩니다. 탐색하는 동안 플로 런타임이 플로 엔진(서버)에 요청을 제출하고 최신 수동 변수 및 수식 값을 반환합니다. 사용자가 단일 화면을 통과할 때 가시성 규칙이 업데이트될 것으로 예상되는 경우(예: onblur) 화면의 다른 구성 요소의 값만 참조해야 합니다.

• Omnistudio를 사용하면 조건부 보기 속성을 설정하여 구성 요소를 조건부로 표시하거나** 숨길 수 있습니다**. 그러나 입력에 대해 둘 이상의 조건부 보기 속성을 추가할 수 없습니다.

조건부 입력 상태

다른 속성을 동적으로 제어해야 하는 경우(예: 필드가 필수인지, 비활성화인지 또는 읽기 전용인지) 몇 가지 옵션이 있습니다. LWC는 입력 상태를 완벽하게 반응형으로 제어합니다. 반응형 화면 플로 구성 요소를 사용하면 이를 지원하는 표준 구성 요소의 구성 요소 특성(예: 읽기 전용, 비활성화됨 및 필수)을 동적으로 제어할 수 있으며, Omnistudio는 구성 요소별 특성의 전체 스펙트럼을 지원합니다. 요구 사항에 따라 Flow가 필요하고 구성 요소가 특정 특성 상태를 지원하지 않는 경우 내장형 LWC를 만들어 동적 입력 상태를 달성할 수 있습니다.

다른 속성을 동적으로 제어해야 하는 경우(예: 필드가 필수인지 또는 읽기 전용인지 여부) LWC를 짧은 시간 동안 사용합니다. 이는 특히 onblur 또는 onclick을 처리하는 방법에 대한 사용자 정의 요구 사항이 있는 경우에 적용됩니다.

화면 플로의 반응형 LWC

화면 플로의 다른 구성 요소에 반응하거나 변경할 수 있는 LWC를 구축하는 경우 화면 플로를 위한 LWC Best Practices for Screen Flows 가이드를 확인하여 구성 요소가 플로 런타임 엔진과 통합되고 의도한 대로 작동하는지 확인합니다.

사용자 정의 이벤트의 경우 일부 입력(또는 전체 양식)이 페이지의 다른 요소와 통신해야 하는 경우 LWC가 유일한 옵션입니다.

• 동일한 DOM 트리 내에서 통신하려면 CustomEvent 인터페이스를 사용합니다.

• DOM을 통해 통신하려면 Lightning Messaging 서비스를 사용합니다.

• 대상 컨테이너에서 Lightning Messaging 서비스가 지원되지 않는 경우 pub/sub 모듈을 사용합니다.

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

• Omnistudio의 경우, Lightning Web Component에서 Omniscript와 통신하는 방법을 확인해 보세요.

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

관리자는 화면 컨테이너 또는 개별 구성 요소에 대해 제한된 화면 및 구성 요소 스타일 재정의 집합(예: 색상, 테두리, 버튼 모양)을 구성할 수 있습니다. 이러한 재정의는 테마 및 브랜딩 뒤에 적용되므로 빌더는 나머지 응용 프로그램에 영향을 미치지 않고 표적화된 시각적 조정을 수행할 수 있습니다.

스타일 재정의는 현지화된 시각적 예외(예: 확인 화면 강조 표시 또는 특정 행동 유도(CTA) 강조)에 사용되며, 전체 스타일링 시스템이 아닙니다. CSS 수준을 제어할 수 없으며 화면 또는 플로에서 재사용할 수 있도록 설계되어 있지 않습니다.

아키텍처 관점에서 스타일링은 다음의 우선 순서를 따라야 합니다.

1. 테마 및 브랜딩: Lightning 테마, 익스피리언스 빌더 브랜딩 집합 또는 LWR 사이트 테마

2. 플로 스타일 재정의: 대상 화면 또는 구성 요소 조정

3. 사용자 지정 구성 요소(LWC): 픽셀 완벽한 제어 또는 재사용 가능한 디자인 패턴이 필요한 경우

테마 및 디자인 시스템을 사용하면 스타일링이 일관되고 확장 가능하며 시간이 지남에 따라 쉽게 유지할 수 있습니다.

• 원하는 스타일 및 CSS는 얼마나 정교합니까?

• 사용자 정의 픽셀 퍼펙트 스타일링 또는 표준 테마가 필요합니까?

FlexCard는 이 가이드에서 도구 내에서 구축하는 UI의 스타일 및 레이아웃(예: 여백 및 패딩, 오타그래픽, 색상 등)을 선언적으로 제어할 수 있는 유일한 제품입니다.

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

CSS에 익숙한 팀은 여러 옵션을 사용할 수 있습니다:

• 플로우 및 LWC는 표준 설계 토큰을 상속합니다.

• Omniscripts 및 FlexCards에는 뉴포트를 통해 맞춤형 디자인 시스템 지원이 포함되어 있습니다.

• LWC를 사용하면 자체 구성 요소를 작성하고 HTML 및 CSS를 완전히 제어할 수 있습니다.

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

참고: Lightning 구성 요소를 플로우에 포함할 수 있습니다. 양식의 모양과 느낌을 픽셀 완벽하게 제어해야 하지만 플로의 다른 혜택(예: 탐색 모델)도 사용하려는 경우 두 가지 모두를 최대한 활용할 수 있습니다. Omniscripts 및 FlexCards에 동일한 원칙이 적용됩니다.

적절한 레이아웃을 선택하는 것은 빠르고 효율적인 데이터 입력을 활성화하고 데이터 무결성을 향상하는 간소화된 양식을 설계하는 데 매우 중요합니다.

• 사용자 경험을 최적화하기 위해 양식 레이아웃을 구성하는 방법은 무엇입니까?

• 사용자가 쉽게 양식에 새 데이터를 입력할 수 있도록 기존 데이터를 사용자에게 표시할 수 있는 방법은 무엇입니까?

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

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

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

LWC를 사용하면 lightning-record-[edit|view]-form과 지원되는 lightning-[input|output]-field를 사용하여 레이아웃을 제어할 수 있습니다. 레이아웃 제한은 HTML 및 CSS에서만 적용됩니다. Lightning-record-form 구성 요소는 관련 페이지 레이아웃의 섹션 구성을 준수합니다(예: 섹션이 페이지 레이아웃에서 2열인 경우 구성 요소에서도 2열).

다른 지역의 사용자 또는 다른 언어를 사용하는 사용자가 양식에 액세스해야 하는 경우 해당 양식을 작성하는 데 사용하는 도구가 현지화 요구 사항을 충족하는지 확인해야 합니다.

참고: 특히 양식의 경우, 현지화 요구 사항은 일반적으로 텍스트 요소를 다른 언어로 번역하는 것을 포함합니다.

• 양식이 두 개 이상의 국가 또는 지역에서 사용될 예정입니까?

• 양식의 텍스트를 다른 언어로 현지화해야 합니까?

사용자 정의 필드를 현지화하는 경우 동적 양식은 번역된 레이블을 준수합니다. 동적 양식은 Lightning 앱 빌더에서 구성 요소 레이블 및 속성에 할당된 모든 사용자 정의 레이블을 준수합니다.

플로는 번역 워크벤치를 통해 모든 표준 및 사용자 정의 화면 구성 요소에 대한 사용자 대면 레이블 번역을 지원합니다.

다음 화면 구성 요소에서 레이블, 도움말 텍스트, 오류 메시지를 현지화할 수 있습니다.

• 텍스트
• 긴 텍스트 영역
• 숫자
• 통화
• 확인란
• 라디오 버튼
• 선택 목록
• 다중 선택 선택 목록
• 확인란 그룹 암호
• 날짜
• 날짜/시간

기본 작업에 대한 내장 번역 지원(예: 이메일 보내기 또는 Chatter 게시)은 없지만 해결 방법이 있습니다. 번역된 레이블을 정의하기 위해 사용자 정의 레이블을 사용하는 경우 Flow Builder에서 해당 레이블을 구성할 때 작업 또는 구성 요소에서 해당 사용자 정의 레이블을 참조할 수 있습니다. 이를 수행하려면 사용자 정의 레이블을 참조하는 플로 수식을 만든 다음, 플로 내의 적절한 위치에서 해당 수식을 참조해야 합니다.

Omniscripts는 번역에 사용자 정의 레이블을 사용합니다. 자세한 내용은 Omniscript가 다국어로 준비되었는지 확인하려면 이 도움말 문서을 확인하십시오.

LWC의 경우, lightning-record-form과 같은 특정 기본 구성 요소는 번역 워크벤치에서 구성된 경우 관련 객체의 필드, 도움말 텍스트, 검증 메시지의 번역을 자동으로 상속합니다.

코드에 새 번역 가능한 레이블을 도입해야 하는 경우 사용자 정의 레이블을 사용하는 것이 좋습니다. 필요한 사용자 정의 레이블을 선언한 다음, @salesforce/label 범위 모듈에서 구성 요소로 가져옵니다.

이 섹션을 사용하여 구현하기 전에 보안, 품질, 운영 제약을 평가합니다.

보안은 복잡한 주제이며 양식 구축 시 명확하지 않은 여러 가지 고려 사항이 있습니다. 기본 수준에서 양식이 올바른 컨텍스트에서 실행되고 사용자에게 기본 데이터에 대해 작업하는 데 필요한 권한이 있는지 확인해야 합니다. 또한 추가 조치를 취하여 잠재적으로 악의적인 코드 또는 URL을 서식 있는 텍스트 필드에서 제거하거나 특정 사용자가 양식에 액세스하지 못하도록 방지하거나 관리자가 향후 양식을 포함할 수 있는 위치 유형에 제한을 적용할 수도 있습니다.

도구를 선택하기 전에 보안 요구 사항을 철저하게 문서화해야 합니다. 이 유형의 문서에 대한 추가 지침은 Salesforce 우수한 보안 정책 템플릿을 참조하십시오.

• 특정 작업을 수행하기 전에 양식에서 사용자의 액세스를 확인해야 합니까?

• 사용자 입력을 정제해야 합니까?

• 양식에 액세스할 수 있는 사람을 제어해야 합니까?

• 양식을 포함할 수 있는 위치를 제어해야 합니까?

프로그램이 사용자 컨텍스트에서 실행되면 Salesforce는 필드 수준 보안, CRUD 권한, 조직의 공유 규칙을 기반으로 레코드 액세스를 확인하는 등 일련의 액세스 검사를 적용합니다(예: 사용자가 사례를 업데이트할 수 있는 기능, 적절한 필드 수준 보안, 해당 레코드에 대한 액세스 권한이 있는 경우에만 사례 업데이트 양식을 실행할 수 있음).

사용자가 다른 양식이나 상호 작용을 통해서가 아닌 양식을 사용할 때 특정 작업을 수행할 수 있도록 하려면 어떻게 해야 합니까? 바로 여기서 시스템 컨텍스트가 사용됩니다!

시스템 컨텍스트를 사용하면 세션 기간 동안 사용자의 권한을 상승시킬 수 있습니다(예: 사용자가 사례 업데이트 양식을 성공적으로 완료하기 위해 사례 개체에 대한 액세스를 업데이트할 필요가 없습니다). 이는 특히 인증되지 않은 커뮤니티에 유용합니다. 게스트 사용자에게 잠재적으로 위험한 기능을 부여하는 대신 시스템 컨텍스트에서 실행되도록 양식을 설정합니다.

시스템 컨텍스트는 절대적으로 필요한 경우에만 사용해야 합니다. 시스템 컨텍스트에서 양식이 실행되면 모든 CRUD 작업이 개체 및 필드 수준 보안 및 공유 구성 요소를 우회합니다. 또한 시스템 컨텍스트는 Salesforce에서 해당 작업자(마지막 수정자 필드에 표시되는 이름)에 영향을 미치지 않습니다. 양식이 수행하는 각 작업(예: 사례 업데이트)에 대해 현재 사용자가 _작업자_입니다(양식이 다른 컨텍스트에서 실행되는 경우에도).

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

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

• 시스템 컨텍스트에서 실행되는 플로우 내에 Lightning 구성 요소를 포함하는 경우, 플로우가 구성 요소의 컨텍스트를 재정의하지 않습니다. 사용자 액세스 검사를 우회해야 하는 경우, 플로우를 사용하여 해당 작업을 수행하고 Lightning 구성 요소에 적절한 데이터를 전달합니다. 일부 기본 구성 요소(예: Lookup)는 시스템 컨텍스트 내에서 작동할 수 없습니다.

• 플로우에서 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을 제거하세요.

• Omniscripts, FlexCards, 그리고 LWCs는 기본적으로 사용자 컨텍스트에서 실행됩니다.

• LWC는 기본적으로 사용자 컨텍스트에서 실행됩니다.

• 플로는 사용자 컨텍스트에서 실행되지만 Apex 컨트롤러를 사용하여 재정의할 수 있습니다.

• UI API 내에서 수행되는 작업은 사용자 컨텍스트에서 실행됩니다.

• Apex 컨트롤러로 수행되는 작업은 특정 클래스에 따라 다릅니다. 이러한 작업을 시스템 모드에서 수행하려면 Apex 클래스를 with sharing 또는 without sharing으로 설정합니다.

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

플로우를 특정 프로필 또는 권한 집합(예: Apex 클래스 또는 Visualforce 페이지와 유사)으로 제한할 수 있습니다. 기본적으로 플로는 제한되지 않습니다. 즉, 플로 실행 사용자 권한이 있는 모든 사용자가 해당 플로에 액세스할 수 있습니다.

Omnistudio를 사용하는 경우 사용자에게 Omniscript, Flexcard, Classic Card 또는 REST API에서 원격 작업을 관리하는 Apex 클래스에 대한 명시적 액세스 권한이 있어야 하는 Apex 클래스 권한 검사기를 구성할 수 있습니다.

참고: Apex 클래스 권한 확인은 Apex 클래스에만 적용됩니다. 또한 통합 절차 및 데이터 매퍼에 대한 프로필 수준 권한을 설정하는 것이 좋습니다.

• 게스트 사용자에게 플로를 노출할 경우 게스트 사용자에게 절대적으로 필요한 플로에 대한 프로필 액세스 권한만 부여해야 합니다. 게스트 사용자 프로필에 실행 플로를 추가할 수 있지만, 이 방법은 위험할 수 있습니다.

• 시스템 컨텍스트에서 작동하는 플로우와 작업할 때 주의하십시오. 데이터를 보호하기 위해 사용할 수 있는 검사 및 균형을 줄여 특정 사용자 집합으로 해당 플로를 제한해야 합니다.

• 게스트 사용자 커뮤니티 내에서 Apex를 실행하는 모든 Omniscript에 Apex 클래스 정의에 with sharing이 명시되어 있는지 확인합니다.

• 게스트 사용자 프로필의 경우 게스트 사용자가 호출하도록 허용할 Apex 클래스만 할당합니다. 이 방법을 수행하면 게스트 사용자에게 의도치 않게 추가 비즈니스 논리가 노출되는 것을 방지할 수 있습니다.

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

LWC는 유효한 대상으로 추가된 후에만 지정된 위치에서 사용할 수 있습니다(예: 레코드 페이지에서 구성 요소를 사용 가능하게 만들고 유틸리티 막대 항목으로 사용할 수 없음).

화면 플로가 활성화되면 화면 플로가 지원되는 모든 위치에서 사용할 수 있습니다. Flow Builder는 화면이 있는 여러 유형의 플로우를 지원합니다. 가장 눈에 띄는 유형은 스크린 플로이지만 특정 위치로 제한되는 몇 가지 다른 전문 유형이 있습니다(예: Field Service 모바일 앱은 Field Service 모바일 플로만 지원). 이는 Experience Cloud에서만 지원되는 연락 요청 플로과 유사합니다.

플로우 유형에 관계없이 플로우를 만드는 사람이 플로우가 포함된 위치를 제어할 수 없습니다. 플로우는 특정 플로우 유형이 지원되는 모든 위치에서 사용할 수 있습니다.

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

Salesforce에는 사용자가 양식과 상호 작용하는 방식을 시뮬레이션할 수 있는 여러 종단 간 테스트 자동화 도구(예: Salesforce UTAM)가 있습니다. Lightning 페이지 및 화면 플로를 비롯한 모든 표준 또는 사용자 정의 UI에 대한 테스트를 작성할 수 있습니다.

참고: 이러한 유형의 테스트는 수행 중인 메서드의 출력을 확인할 수 없습니다. UI 테스트 자동화 요구 사항을 구성할 때 이 사항에 유의하십시오.

• 양식에 대한 자동 테스트가 필요합니까?

• 수행할 테스트 유형은 무엇입니까?

• 테스트 자동화에 필요한 세분화 수준은 어느 정도입니까?

UI 테스트 자동화 요구 사항 고려

비즈니스 논리, JavaScript 제어, 특정 구성 요소의 출력을 테스트하는 업계 표준 CI/CD 시스템 및 도구와 일치하는 세분화된 자동화 및 검증을 제공하는 유닛 테스트 로우코드 접근 방식을 선택하는 경우 테스트를 자체 작성할 수 없지만, Salesforce는 모든 종단 간 제공 기능을 엄격하게 테스트합니다.

구성 요소의 메서드가 복잡한 경우 메서드를 전용 JavaScript 파일에 배치하여 개별적으로 텍스트를 작성할 수 있습니다. 이렇게 하면 이를 LWC에 가져온 후, 예를 들어 import { sort } from ‘c/utils’;와 같이 Jest 테스트로 가져올 수 있습니다.

ISV의 코드 없는 솔루션을 사용하고, 사용자 정의 테스트 자동화 솔루션을 구축하거나, 전체 자동화를 위해 오픈 소스 테스트 프레임워크(예: Selenium WebDriver 또는 WebdriverIO)를 사용할 수 있습니다. 이러한 솔루션은 모든 Salesforce UI 상호 작용에 유효합니다(예: Lightning 페이지의 동적 양식, 유틸리티 막대의 화면 플로 또는 빠른 작업 플로의 LWC).

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

• 양식 사용을 추적해야 합니까?

• 양식이 효과적으로 사용되고 있는지 여부를 판별할 수 있는 KPI는 무엇입니까?

전체 양식 사용 및 채택을 추적해야 하는 경우 로우코드 도구를 사용하십시오. 동적 양식 및 스크린 플로우는 기본 사용자 정의 보고서를 통해 추적할 수 있습니다. 그러나 스크린 플로우 추적 보고서는 추가 세분화를 제공합니다. LWC 사용을 추적해야 하는 경우 기본 제공 가용성은 LWC를 사용하는 위치에 따라 다릅니다. Lightning 페이지에 있는 경우 사용 가능한 Lightning 페이지 사용 추적 요소가 모두 LWC에 적용됩니다. 플로에 포함된 LWC에도 마찬가지입니다.

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

플로우는 특정 양식의 채택을 추적하는 데 도움이 됩니다. 샘플 플로우 보고서 사용: 다음 유형의 질문에 답하기 위한 스크린 플로우:

• 이 양식의 완료율은 얼마입니까? 현재 제대로 채택되어 있습니까?

• 사용자가 이 양식을 작성하는 데 시간이 얼마나 걸립니까?

• 사용자가 가장 많은 시간을 할애하는 화면은 무엇입니까?

• 사용자가 이전 화면으로 얼마나 자주 이동합니까?

• 오류는 얼마나 자주 발생합니까?

표준 보고서가 요구 사항을 충족하지 않는 경우 복제하고 변경하거나 스크린 플로 보고서를 사용하여 처음부터 Build Your Own 보고서를 만들 수 있습니다.

패키지 기반 Omniscript 런타임을 사용하는 경우 Vlocity 추적 서비스용 Omnistudio도 사용할 수 있습니다. 이 서비스는 모든 유형의 이벤트를 추적합니다(예: Omniscript에서 단계를 완료하는 데 걸리는 시간을 추적할 수 있으므로 프로세스 개선 사항을 식별하는 데 도움이 됩니다).

참고: 화면 플로우, Omniscript 또는 Lightning 페이지에 포함되지 않은 LWC를 추적하는 기본 옵션은 없지만, Apex를 사용하여 사용자 정의 솔루션을 구축할 수 있습니다.

변경 집합 또는 DevOps Center를 사용하여 테스트 환경 또는 프로덕션에 솔루션을 배포하는 방법을 숙지할 수 있습니다. 해당 배포 옵션은 동적 양식, 플로, LWC를 완전히 지원합니다. 그러나 Omnistudio는 별도의 도구인 IDX 워크벤치가 필요합니다.

• 양식을 배포할 계획은 무엇입니까?

• 양식을 둘 이상의 Salesforce 조직에 배포해야 합니까?

ISV 또는 AppExchange 배포를 위해 솔루션을 패키지하려는 파트너인 경우 동적 양식, 플로, LWC를 확인하십시오. Omnistudio는 패키징을 지원하지 않습니다.

이 가이드는 동적 양식, 화면 플로, Omnistudio, LWC를 통해 사용할 수 있는 기능 및 사용자 정의 수준을 보여줍니다. 다음은 상위 수준의 개요입니다.

• 양식 구축 시 LWC는 가장 강력하고 사용자 정의 가능한 옵션이지만 가드 레일이 가장 적습니다. 따라서 구성 요소를 보안 및 확장성을 고려하여 구축하는 것이 중요합니다.

• 동적 양식은 가장 유연하지 않은 옵션이지만, 오류가 발생할 가능성이 훨씬 적습니다.

• Flow와 Omnistudio는 중간 정도의 위치에 있습니다. 동적 양식보다 강력하지만 LWC 수준까지는 달라지지 않습니다. 그러나 동적 양식보다 가드 레일이 적으며 사용자 정의 코드보다 깨지기 어려워집니다.

필요에 맞는 여러 도구를 찾을 수 있습니다. 이러한 경우 최종적으로 결정은 팀에 가장 적합한 도구에 따라 다릅니다. 고려해야 할 추가 측면에 대한 자세한 내용은 이러한 아키텍트 의사 결정 가이드를 참조하십시오.

• 도구를 비교할 때 팀이 각 도구와 관련하여 얼마나 많은 전문 지식을 보유하고 있는지 평가하는 것이 중요합니까?
• LWC 또는 JavaScript에 능숙한 개발자는 몇 명입니까?
• 팀에 Flow Builder에 대한 전문가이거나 추가 학습에 관심을 보인 개발자가 있습니까?

자세한 내용은 살펴보지 않지만, 다음은 이러한 특정 도구가 지금까지 다루고 있는 평가와 어떻게 관련되어 있는지에 대한 더 많은 정보입니다.

제공 위임

일부 요구 사항이 LWC를 요구하더라도 LWC를 사용하여 전체 솔루션을 구축하지 않아도 됩니다. 솔루션을 모듈 방식으로 구축할 수 있는 방법을 결정하는 것이 중요합니다. 이를 수행하려면 코딩된 LWC가 필요한 부분과 그렇지 않은 부분을 구분해야 합니다. LWC가 필요하지 않은 부품은 로우코드 솔루션을 사용하여 구축해야 합니다.

Flow와 LWC에서는 동일한 화면에서 상호 동기화가 가능한 다양한 구성 요소들(예: 반응형 화면 구성 요소 및 화면 Flow)이 존재해 아키텍트, 관리자, 그리고 개발자에게 새로운 도구를 제공합니다. 개발자는 이제 조직 전체에서 재사용할 수 있는 목적에 부합하는 모듈식 구성 요소를 만들어, 팀 생산성을 향상시킬 수 있습니다. 이로 인해 개발자는 표준 및 사용자 정의 Flow 구성 요소를 혼합하여 양식에 동적 효과를 부여함으로써 시간을 절약하고, 새로운 문제 해결에 더 많은 시간을 할애할 수 있습니다. 플로에 반응형 구성 요소가 도입됨에 따라, 양식 구축 시 Flow와 LWC를 혼용하기에 이보다 적절한 때는 없었습니다.

장기 소유 및 유지 보수

다단계 양식을 만드는 경우 Flow 또는 Flow와 LWC를 함께 사용하여 시작합니다. 양식을 유지 관리하는 팀이 로우코드 팀인 경우 솔루션이 의도한 대상에 대해 최대한 구성 가능하고 확장 가능한지 확인하십시오. 안정성과 유지 보수성 향상을 위해 선택한 도구와 상관없이 솔루션을 복합 가능한 유닛으로 구성하는 것이 중요합니다.

동적 양식, 화면 플로, Omnistudio 또는 LWC와 관련된 성능 고려 사항은 기술이 포함된 프레임워크를 기반으로 합니다. LWC를 기반으로 하는 기술은 Aura를 기반으로 하는 기술보다 성능이 뛰어난 경향이 있습니다. 프레임워크 추상을 통해 JavaScript가 아닌 웹 엔진에서 기본적으로 구현되는 몇 가지 핵심 기능으로 인해 LWC는 향상된 성능 혜택을 제공합니다.

Salesforce의 양식 기술에 대한 이러한 성능 혜택을 어떻게 활용합니까? 자세히 살펴보겠습니다.

• Dynamic Forms(Lightning 페이지 메타데이터 내에서 통합)는 LWC 스택 기반으로 구축되며, 오랫동안 기다려온 여러 기능을 구현할 수 있습니다. Dynamic Forms는 추가적인 성능 향상으로 프로그레시브 렌더링을 사용하여 필드가 많은 페이지의 로드 시간을 개선합니다.

• 화면 플로는 LWC를 기반으로 구축됩니다. 대부분의 개별 기본 제공 구성 요소는 이제 파일 업로드 및 이미지 구성 요소를 제외하고 LWC로 전환되었습니다. Flow 팀이 플로 런타임 클라이언트(및 대부분의 구성 요소)를 LWC로 전환했지만, 고객은 여전히 자신의 Aura 화면 구성 요소를 LWC로 변환해야 합니다. Salesforce는 화면 플로의 반응형 구성 요소 프레임워크 내에서만 LWC 구성 요소를 지원합니다. 자세한 내용은 Lightning Web Components for Aura Developer Trailhead 모듈을 참조하십시오. Screen Flow(또는 기타 컨테이너)에 사용할 사용자 정의 구성 요소를 제작할 계획이라면, LWC를 선택하세요!

• 사용할 수 있는 여러 버전의 Omnistudio가 있습니다. 장기 고객이라면 Angular를 사용하고 있을 수 있습니다. 모든 신규 고객에게는 LWC 기반 Omniscript 및 FlexCard 사용을 권장합니다. 기존 고객에게도 Angular에서 벗어나도록 권장합니다.

• LWC는 LWC를 기반으로 구축됩니다.