변수, 경로 및 루프 살펴보기

[내레이터] Salesforce 플로에 대해 알아보고 싶으시다고요? 이를 위해서는 변수의 개념을 이해하는 것이 중요합니다. 간단히 요약하자면, 플로의 변수는 특정 조건에 의해 값이 변화할 수 있는 경우에 사용됩니다. 변수는 정보가 담긴 컨테이너일 뿐입니다. 플로의 모든 변수는 이름과 값이 있습니다. 플로 내에서 이동하면서 변수의 값에 액세스할 수도 있고, 값을 변경할 수도 있습니다. 그래서 이름이 '변수'인 거죠.

점심 도시락에 비유해볼까요? 도시락통은 변수입니다. 도시락통 이름은 '내 점심', 값은 샌드위치로 가정해보겠습니다. 월요일에는 도시락통, 즉 변수에 샌드위치를 담습니다. 화요일에는 변수인 같은 도시락통을 재사용하여 피자 한 조각을 담습니다. 변수는 마치 도시락통과도 같이 비어있거나 가치가 없을 수도 있습니다. 지금까지 변수의 일반적인 개념을 알아보았으니 다음으로 플로 내 변수의 역할을 살펴보겠습니다.

예를 들어, 플로 내 변수의 이름이 연락처 ID일 수 있습니다. 연락처 ID 변수의 값이 계정의 기본 연락처 ID라고 가정해보겠습니다. 플로는 계정 개체의 모든 연락처를 스캔하여 특정 기능을 찾고 다른 사람을 기본 연락처로 지정해야 한다는 결론을 내립니다. 그런 다음 플로는 새 연락처 ID를 연락처 ID 변수에 할당합니다. 이 변경 사항은 아직 Salesforce org에 저장되지 않았다는 사실에 반드시 유의하세요. 변수는 플로 내에 있는 정보가 담긴 컨테이너입니다. 이러한 변경 사항은 여러분이 Salesforce org에 저장하라는 지시를 내릴 때까지 저장되지 않습니다.

축하합니다! 변수를 이해하기란 어려울 수 있습니다. 변수는 플로 내에 있을 때는 정보를 포함하고, 변수의 값은 변경될 수 있으며, 플로가 조직의 실제 데이터를 변경하기 전에 몇 가지 단계를 거쳐야 한다는 사실을 기억하세요.

[나레이터] 오늘 도시락 강의에 오신 것을 환영합니다. 최초의 상업용 도시락은 19세기에 발명되었습니다. 농담입니다. 음, 이 동영상은 모두 변수에 관한 내용입니다. 도시락은 Flow Builder를 가리킵니다. 변수는 정보를 담는 용기라는 뜻이죠. 도시락통이 다른 음식을 담는 것과 비슷한 것처럼 말이죠.

그러나 플로 도시락통의 데이터 형식은 동일하게 유지되지만, 내부에 있는 데이터의 가치는 플로 전반에 걸쳐 변경될 수 있습니다. 보온병은 액체를 담기 위한 것입니다. 그렇죠? 이와 같이, 텍스트 데이터 형식이 있는 변수는 텍스트를 보유하며, 숫자 데이터 형식이 있는 변수는 숫자를 보유합니다.

Salesforce 필드를 구축한 경우 변수 유형, 텍스트, 숫자, 통화, 날짜, 날짜/시간, 선택 목록에 대한 많은 선택 사항을 숙지해야 합니다. 하지만 몇 가지 생소한 내용이 있을 수 있습니다. 부울은 참, 거짓 또는 빈 값을 저장하는 데 사용됩니다. 체크박스 필드와 비슷합니다. 단, 이 빈 칸은 false와 같지 않습니다. 공백은 널(null) 또는 없음(nothing) 를 의미한다. 또 다른 변수 타입은 Apex가 정의되어 있습니다. 이 변수 데이터 형식은 일반적으로 Apex 코드에서 반환되거나 웹 서비스로 호출되는 복잡한 데이터 개체를 조작합니다. 변수 유형을 선택하면 여러 값을 허용하는 옵션이 있습니다. 즉, 변수를 컬렉션 변수로 바꾼 것이죠.

샌드위치를 많이 담기 위해 더 큰 도시락을 사는 것과 비슷합니다. 컬렉션 변수는 동일한 유형의 변수 컬렉션만 포함합니다. 예를 들어, 숫자 변수는 다른 숫자와만 결합할 수 있습니다. 샌드위치가 다른 샌드위치와 함께 컬렉션에 있는 것과 같이, 연락처 레코드는 다른 연락처 레코드와 함께 컬렉션에 있는 것만 가능합니다. 컬렉션에서 개체를 혼합할 수 없습니다.

결론적으로, 변수 유형은 레코드의 필드 유형과 유사합니다. 모든 변수 유형은 해당 유형의 변수 컬렉션에 있을 수 있습니다. 도시락이 타코를 담을 수 있는 용기라면 점심에는 타코만 먹는 셈입니다. 그리고 평소처럼 항상 sandbox 조직에서 플로를 테스트합니다.

[나레이터] Salesforce에서 트레일에 대해 많이 이야기하지만, 몇 분 동안 특별히 예약 경로에 대해 집중해 보겠습니다. 레코드 트리거 플로에서 예약 경로를 사용하여 즉시 플로 작업을 예약하지 않고 향후 플로 작업을 예약합니다.

예를 살펴보겠습니다. 리드 레코드가 생성되면 플로가 진행됩니다. 플로는 이 레코드가 생성됨에 따라 트리거됩니다. 예약 경로를 사용하여 생성일로부터 3일 후에 리드에게 이메일을 보내는 것과 같이 분, 시간 또는 일 이후에 어떤 작업이 발생됩니다. 생성된 날짜를 기준으로 일정을 잡는 것만으로는 제한되지 않습니다. 예약 경로는 개체의 모든 날짜 또는 날짜/시간 필드를 기반으로 설정할 수 있으며, 해당 날짜, 해당 날짜 이후나 이전에도 시작할 수 있습니다.

연락처가 생성될 때 멤버십 만료일을 설정하는 레코드 트리거 플로가 있다고 가정해 보겠습니다. 같은 플로에서 멤버십이 만료되기 5일 전에 이메일 리마인더를 보낼 수 있습니다. 워크플로 규칙 또는 프로세스 빌더에 익숙한 경우 예약 경로는 프로세스 빌더에서 시간 제한이 있는 워크플로우 규칙 또는 시간 기반 작업과 동일합니다.

이제 예약 경로처럼 보일 수 있지만 그렇지 않은 두 가지 내용에 대해 살펴보겠습니다. 레코드 트리거 플로의 시작 요소는 외부 시스템에 액세스하기 위한 비동기 실행 경로를 포함하는 옵션을 제공합니다. 더 발전된 플로가 필요할 때까지 이를 무시할 수 있습니다. 그리고 예약 트리거 플로를 혼돈하지 마세요. 이는 한 번, 매일 또는 일주일에 한 번 실행할 수 있는 플로 유형입니다. 예를 들어, 한 달에 한 번 실행되도록 예약 트리거 플로를 설정하여 해당 기간 동안 변경되지 않은 리드를 cold(콜드)로 표시할 수 있습니다.

즉, 레코드 트리거 플로에서 예약 경로를 사용하여 플로가 처음 트리거된 후 언제든지 수행된 단계를 자동화합니다. 레코드를 예약 경로에 설정하려면 레코드를 생성하거나 업데이트해야 합니다. 예약 경로는 개체의 모든 날짜 또는 날짜/시간 필드를 기반으로 할 수 있습니다. 항상 그렇듯이 sandbox에서 먼저 플로를 테스트하는 것을 잊지 마세요.

[내레이터] 플로 루프라는 주제는 복잡하지만,당황할 필요는 없습니다. Flow Builder의 루프는 레코드 목록과 같은 컬렉션을 살펴보고 각 레코드에 기반하여 작업을 수행합니다.

플로 루프는 굉장히 강력하여 데이터베이스에서 한 번에 수백 개의 레코드를 생성하고 업데이트하고 삭제할 수 있습니다. 플로의 루프는 복잡하게 보일 수 있지만, 실제 애플리케이션에 적용해보면 더 쉽게 이해할 수 있습니다.

그러면 주말에 냉장고를 정리하려는 오스카의 예를 살펴보겠습니다. 오스카는 Salesforce 레코드 대신 냉장고에 남은 음식에 대해 플로 루프의 모든 단계를 수행할 예정입니다. 플로가 수행할 수 있는 조치인 플로 요소가 냉장고 청소와 어떤 상관관계에 있는지 간단히 알아보겠습니다.

우리가 필요로 하는 첫 플로 요소는 레코드 가져오기입니다. 또한 우리는 기준을 통해 가져올 레코드를 결정합니다. 이 예에서 오스카는 라벨 표시가 없는 남은 음식을 모두 가져옵니다. 다음으로 루프 요소를 추가해야 합니다. 플로는 루프를 거치며 한 번에 하나씩 레코드를 평가합니다. 즉, 이 예에서 오스카는 음식을 한 번에 한 가지씩 확인합니다. 다음으로 결정 요소를 추가합니다. 남은 음식을 계속 보관할까요, 아니면 버릴까요? 결정 요소는 플로 루프의 필수 요소는 아니지만 이 예에서는 필요합니다. 업데이트할 레코드에는 할당 요소를 추가하여예 컨대 날짜 필드 업데이트와 같이 원하는 변경 사항을 표시합니다. 이 예에서 오스카는 이 음식을 계속 보관하기로 하고, 오늘 날짜가 적힌 라벨을 부착합니다. 우리는 두 번째 할당 요소를 추가합니다. 이는 컨테이너와 같죠. 우리는 보관할 모든 레코드를 일시적으로 담을 컨테이너로 레코드를 가져옵니다. 이는 오스카가 보관할 남은 음식을 상자에 담는 것과 같습니다. 이제 첫 번째 레코드가 루프를 모두 거쳤으니, 다음 레코드로 이 과정을 반복합니다.

오스카는 다음 음식을 확인해봅니다. 결정 요소 후에는 플로가 수행할 수 있는 또 다른 경로를 만들어야 합니다. 오스카는 보관하지 않을 남은 음식을 어떻게 처리할까요? 할당 요소를 하나 더 추가해보겠습니다. 이번에는 삭제할 레코드를 컨테이너에 보관하겠습니다. 오스카가 보관하지 않을 음식을 담을 컨테이너는 음식물 쓰레기통입니다. 이어서 다음 항목의 루프가 시작됩니다. 이렇게 모든 레코드의 루프를 완료합니다. 루프 후에는 데이터베이스를 실제로 변경해야 합니다. 상자와 음식물 쓰레기통은 항목을 일시적으로 보관할 뿐입니다.

레코드 업데이트 요소를 플로에 추가하여 레코드를 보관하는 변경 사항을 확정합니다. 앞서 보관할 항목에 날짜 값을 추가했었죠. 오스카는 상자를 다시 냉장고, 즉 데이터베이스에 넣습니다. 레코드 삭제 요소를 추가하여 원하지 않는 레코드를 폐기합니다. 오스카의 경우 야외의 쓰레기통을 이용하면 됩니다. 오스카는 각각의 음식을 하나씩 버리는 대신 모든 음식을 한꺼번에 야외의 음식물 쓰레기통에 버립니다. 한 번씩 버리면 시간이 낭비되니까요. 플로도 마찬가지입니다. 이 그림의 업데이트 및 삭제 요소와 같이 데이터 요소를 루프 외부에 보관하는 것이 좋습니다. 루프 중에 레코드를 할당 요소로 보내면 루프가 끝난 후 업데이트하겠다는 의미입니다. 즉, 우선 미뤄뒀다 나중에 처리하겠다고 표시하는 것과 같습니다. 모든 변경을 한꺼번에 수행하는 게 훨씬 더 효율적입니다. 모든 음식물 쓰레기를 하나의 용기에 담아 밖에 버리는 것처럼요.

축하합니다. 플로 루프에 대해 알아보았을 뿐 아니라 오스카가 냉장고를 효율적으로 정리할 수 있게 도와주셨네요. 오스카가 다음에 또 도움을 요청하면 도와주세요.

[나레이터] Flow Builder 자동화에 약간의 문제 해결이 필요한 문제가 있습니다. 좋은 소식이 있습니다. Flow Builder에는 디버그 도구가 기본으로 제공됩니다. 디버깅을 통해 문제를 식별하고 소스를 분리할 수 있기 때문에 문제를 수정하거나 해결 방법을 결정할 수 있습니다. 자동화는 항상 완벽하게 설정되고 문제가 되지 않으므로 디버그 도구는 필요하지 않다고 알고 계실 것입니다. 하지만 가장 경험이 풍부한 Flow Builder 전문가의 경우에도 절대 그렇지 않습니다.

Flow Builder 디버그 도구는 빌딩 플로에 반드시 필요합니다. Flow Builder의 디버그 도구로 작업을 마치면 결과 분석이 표시됩니다. 자동화에 성공했나요? 실패했나요? 어디서 실패했을까요? 결과 세부 정보에는 인터뷰가 시작된 방법, 플로를 촉발시킨 요인, 기록적 상호 작용 발생 요인, 해당 조치가 성공적이었는지 여부가 요약되어 있습니다.

Flow Builder 디버그 도구는 문제 해결뿐 아니라 초기 테스트에도 유용합니다. 기능에는 프로덕션에 들어가기 전에 자동화를 테스트하는 것이 포함됩니다. 디버그 중에 특정 입력 변수를 지정합니다. 자동화의 다른 경로를 디버깅합니다. 레코드가 생성, 업데이트 또는 삭제된 것처럼 플로를 트리거합니다. 다른 사용자로 자동화를 실행합니다. 그리고 디버그의 세부 사항과 해당 경로를 생성합니다. 새 자동화를 만들거나 문제가 있는 기존 자동화를 수정할 때 Flow Builder 디버그 도구를 사용합니다.

Flow Builder에서 디버깅할 때 조직 내 데이터와 실제로 상호 작용한다는 것을 기억하세요. 바로 이것이 sandbox 조직에서 항상 플로를 디버깅해야 하는 이유입니다. sandbox 조직에서 테스트할 때 사용할 수 있는 매우 유용한 기능은 롤백 모드 옵션입니다. 플로를 디버깅할 때 롤백 모드를 사용하는 경우, Flow Builder는 자동화가 끝난 후 자동화가 조직에 미치는 변화를 롤백합니다.

정리하겠습니다. 모든 새로운 또는 업데이트된 Flow Builder 자동화는 디버그로 테스트해야 합니다. 디버그는 입력 변수 지정, 플로 요소 결과 드러내기, 다른 사용자로 자동화 실행과 같은 수많은 기능을 가지고 있습니다. 가장 좋은 방법은 sandbox 조직에서 디버깅하고 롤백 모드를 사용하는 것입니다.