Salesforce Flow Builder로 업무 요청 라우팅 자동화를 만들 때는 먼저 요청 데이터가 들어오는 위치, 담당자 배정 기준, 실패했을 때 사람이 확인할 예외 경로를 한 장으로 정리하는 것이 빠릅니다. 그 다음 Flow Builder에서 시작 조건, 의사결정 분기, 레코드 업데이트 또는 알림 동작을 단계별로 붙이면 됩니다. 화면 이름, 제공 기능, 라이선스 범위, 관리자 메뉴 위치는 Salesforce 릴리스와 조직 설정에 따라 달라질 수 있으므로 실제 적용 전에는 공식 도움말과 현재 사용 중인 조직 화면을 함께 확인하세요.
핵심 요약: Flow Builder는 Salesforce 안의 반복 업무를 조건과 동작으로 연결하는 도구입니다. 업무 요청 라우팅 글에서는 “누가 요청을 만들고, 어떤 기준으로 분류하고, 어느 담당자에게 넘기며, 누가 실패를 확인하는가”를 먼저 정한 뒤, 레코드 트리거 흐름과 조건 분기를 작게 만들어 테스트하는 순서를 권합니다.
1. 이 자동화가 필요한 상황부터 확인하기
영업, 고객 운영, 내부 지원 팀은 Salesforce 안에서 매일 비슷한 요청을 처리합니다. 예를 들어 새 리드가 들어오면 담당 영업 그룹에 넘기고, 기존 고객의 변경 요청은 계정 소유자에게 전달하며, 우선순위가 높은 요청은 별도 채널로 알려야 합니다. 이 과정을 사람 손으로만 처리하면 담당자 기준이 흔들리고, 휴가나 인수인계 때 누락이 생기기 쉽습니다. Flow Builder 업무 요청 라우팅 자동화는 이런 반복 배정을 일정한 기준으로 묶는 방법입니다.
다만 처음부터 모든 예외를 넣으려고 하면 흐름이 복잡해집니다. 첫 버전은 한 개 객체, 한 개 요청 유형, 두세 개 담당자 기준만 다루는 것이 좋습니다. 요청 생성자가 영업인지, 고객 운영인지, 외부 폼인지에 따라 입력 필드가 달라지므로 출발 지점을 먼저 고정해야 합니다.
2. Flow Builder가 하는 역할을 간단히 이해하기
Salesforce 도움말은 Flow Builder를 사용자가 입력을 제공하거나 Salesforce 안의 조건이 맞을 때 어떤 일을 수행하도록 만드는 자동화 도구로 설명합니다. 또 Workflow Rules와 Process Builder가 Flow 중심으로 전환되는 흐름도 공식 안내에서 확인할 수 있습니다. 즉 새 자동화나 기존 자동화 전환을 검토한다면 Flow Builder 기준으로 설계하는 편이 장기 운영에 유리합니다.
업무 요청 라우팅에서는 보통 레코드 생성이나 변경을 시작점으로 잡고, 조건 분기에서 요청 종류와 우선순위를 판단한 뒤, 레코드의 소유자나 상태를 바꾸거나 작업 항목을 생성합니다. 필요한 경우 알림이나 후속 작업을 붙일 수 있지만, 첫 구축 단계에서는 “배정 기준이 정확한가”를 먼저 보는 것이 안전합니다.
3. 만들기 전 준비할 입력값 표
Flow 화면을 열기 전에 아래 표를 채우면 시행착오가 줄어듭니다. 이 표는 관리자와 현업 담당자가 같은 기준을 보고 이야기하기 위한 초안입니다.
| 확인 항목 | 예시 | 주의할 점 |
|---|---|---|
| 요청 객체 | Lead, Case, Task, 사용자 정의 객체 | 한 번에 여러 객체를 섞지 않습니다. |
| 시작 조건 | 새 요청 생성, 상태 변경, 우선순위 변경 | 너무 넓게 잡으면 불필요한 실행이 늘어납니다. |
| 분류 기준 | 지역, 제품군, 고객 등급, 요청 유형 | 필드 값이 비어 있을 때의 기본 경로가 필요합니다. |
| 담당자 기준 | 큐, 사용자, 팀 소유자 | 퇴사자나 비활성 사용자 배정을 막아야 합니다. |
| 예외 처리 | 기본 담당 큐, 관리자 확인 목록 | 실패를 조용히 넘기지 않는 구조가 좋습니다. |
4. 작은 라우팅 규칙부터 설계하기
첫 흐름은 “조건 하나가 맞으면 담당 큐를 바꾼다” 정도로 단순하게 시작합니다. 예를 들어 요청 유형이 ‘견적 문의’이면 영업 큐로, ‘계정 정보 변경’이면 고객 운영 큐로 넘기는 식입니다. 이렇게 작은 흐름을 만들면 테스트 데이터도 명확해지고, 운영자가 결과를 이해하기 쉽습니다.
조건이 많아질수록 이름 규칙이 중요합니다. 의사결정 요소에는 “요청유형_견적문의”, “우선순위_높음”처럼 결과가 바로 보이는 이름을 붙입니다. 담당자 변경 요소도 “소유자_영업큐_배정”처럼 남겨 두면 나중에 흐름을 열었을 때 전체 구조를 빠르게 파악할 수 있습니다.
5. Flow Builder에서 구성할 기본 순서
- Salesforce 설정 화면에서 Flow Builder를 열고 새 흐름 유형을 선택합니다.
- 요청 레코드가 만들어지거나 바뀌는 조건을 시작점으로 설정합니다.
- 요청 유형, 지역, 우선순위처럼 라우팅에 쓸 필드를 확인합니다.
- Decision 요소로 담당자 또는 담당 큐를 나누는 조건을 만듭니다.
- Update Records 또는 관련 동작으로 소유자, 상태, 다음 작업을 바꿉니다.
- 기본 경로를 만들어 조건에 걸리지 않는 요청도 사람이 확인하게 둡니다.
- 테스트 레코드로 각 분기 결과를 확인한 뒤 활성화합니다.
이 순서는 조직마다 조금씩 달라질 수 있습니다. Salesforce 릴리스, 권한, 설치된 패키지, 객체 구조에 따라 보이는 메뉴와 선택 가능한 동작이 다를 수 있으므로 실제 화면에서 표시되는 설명을 우선 확인해야 합니다.
6. 테스트는 성공 사례보다 예외 사례를 먼저 보기
자동화 테스트에서는 “정상 요청이 정상 담당자에게 갔다”만 보면 부족합니다. 필수 필드가 비어 있는 요청, 담당자가 비활성 상태인 요청, 조건이 겹치는 요청, 어떤 조건에도 맞지 않는 요청을 따로 만들어야 합니다. 이런 데이터로 테스트하면 운영 중에 조용히 쌓이는 미배정 요청을 줄일 수 있습니다.
테스트 기록은 단순히 성공 여부가 아니라 입력값, 예상 담당자, 실제 담당자, 수정한 조건을 함께 남깁니다. 나중에 라우팅 기준이 바뀌면 이 기록이 회귀 점검표가 됩니다. 특히 여러 팀이 같은 객체를 쓰는 조직에서는 한 팀의 조건 추가가 다른 팀의 배정을 바꾸지 않는지 확인해야 합니다.
7. 현업 담당자에게 설명하기 쉬운 운영 체크리스트
- 요청이 들어오는 필드와 화면을 현업 명칭으로 정리했습니다.
- 담당자 배정 기준을 문장으로 설명할 수 있습니다.
- 조건에 맞지 않는 요청이 들어갈 기본 큐가 있습니다.
- 자동화가 실행된 뒤 사람이 확인할 목록 또는 대시보드가 있습니다.
- 변경 요청이 들어오면 테스트 레코드로 먼저 확인합니다.
- 릴리스 후 첫 며칠 동안 미배정·오배정 요청을 별도로 봅니다.
8. 기존 Workflow나 Process Builder가 있다면
Salesforce는 기존 Workflow Rules와 Process Builder에서 Flow로 전환하는 흐름을 안내하고 있습니다. 이미 오래된 자동화가 있다면 새 라우팅을 만들기 전에 같은 객체에서 실행되는 기존 규칙을 확인해야 합니다. 같은 레코드를 여러 자동화가 동시에 바꾸면 담당자 값이 마지막 실행 결과로 덮일 수 있습니다.
전환은 한 번에 모두 옮기기보다 우선순위가 낮고 구조가 단순한 규칙부터 시작하는 편이 낫습니다. 기존 자동화의 조건, 실행 시점, 바꾸는 필드를 표로 적고, 새 Flow에서 동일한 결과가 나오는지 비교합니다. 운영 중인 조직에서는 비활성화 전에 백업 설명과 테스트 결과를 남겨 두어야 합니다.
9. 운영 중 자주 생기는 문제와 대응
가장 흔한 문제는 조건 순서가 겹치는 경우입니다. 예를 들어 지역 기준과 우선순위 기준이 동시에 맞으면 어떤 분기가 먼저 실행되는지 명확해야 합니다. 두 번째 문제는 필드 값 표기가 현업 입력과 자동화 조건에서 다를 때입니다. 드롭다운 값과 텍스트 입력값이 섞이면 예상보다 많은 요청이 기본 큐로 빠질 수 있습니다.
세 번째 문제는 담당자 기준이 조직 변경을 따라가지 못하는 경우입니다. 팀 이름, 큐 구성, 사용자 권한이 바뀌면 흐름 자체는 정상이어도 결과가 어긋날 수 있습니다. 그래서 분기 기준만 점검하지 말고 담당 큐와 사용자 상태도 정기적으로 확인하는 운영 루틴이 필요합니다.
10. 비용과 기능 범위는 현재 계약 기준으로 확인하기
Flow Builder 자체는 Salesforce 조직의 에디션, 권한, 사용 중인 기능 범위에 따라 접근 방식이 달라질 수 있습니다. 일부 고급 동작, 외부 연동, 대량 처리, 샌드박스 구성은 조직의 계약과 설정에 영향을 받을 수 있습니다. 따라서 글의 순서를 그대로 따라 하기보다, 현재 조직의 관리자 권한과 공식 도움말에서 표시되는 기능을 함께 확인하는 것이 안전합니다.
특히 앱 설치, 외부 서비스 연결, 추가 자동화 패키지 사용은 별도 승인 절차가 필요할 수 있습니다. 이 글은 일반적인 IT·오피스 자동화 흐름을 정리한 것이며, 각 조직의 내부 운영 기준과 Salesforce 관리자 정책을 대체하지 않습니다.
11. FAQ
Q1. Salesforce Flow Builder를 처음 쓰면 어떤 자동화부터 만드는 것이 좋나요?
한 개 객체에서 새 요청이 생성될 때 담당 큐를 바꾸는 흐름처럼 작고 검증하기 쉬운 자동화부터 시작하는 것이 좋습니다. 조건과 결과가 명확해야 현업 담당자가 빠르게 확인할 수 있습니다.
Q2. 업무 요청 라우팅에 필요한 필드는 무엇인가요?
요청 유형, 우선순위, 지역, 제품군, 현재 상태, 담당 큐처럼 배정 기준에 직접 쓰이는 필드가 필요합니다. 필드 값이 비어 있을 때 들어갈 기본 경로도 함께 정해야 합니다.
Q3. 기존 Process Builder가 있으면 바로 Flow로 옮겨야 하나요?
공식 안내에서 Flow 중심 전환 흐름을 확인할 수 있지만, 운영 중인 자동화를 한 번에 바꾸는 것은 위험합니다. 기존 조건과 결과를 문서화하고 테스트 레코드로 비교한 뒤 단계적으로 전환하는 편이 안전합니다.
Q4. 라우팅 자동화가 잘못 배정하면 어떻게 줄일 수 있나요?
조건이 겹치는 사례, 필드가 비어 있는 사례, 어떤 조건에도 맞지 않는 사례를 테스트에 넣어야 합니다. 또한 기본 큐와 운영 점검 목록을 두면 조용히 누락되는 요청을 빨리 발견할 수 있습니다.
Q5. 화면이나 메뉴가 글과 다르면 어떻게 해야 하나요?
Salesforce는 릴리스와 조직 설정에 따라 화면, 메뉴명, 제공 기능이 달라질 수 있습니다. 현재 조직 화면과 공식 도움말을 우선 기준으로 삼고, 필요한 경우 Salesforce 관리자에게 현재 권한 범위를 확인하세요.
12. 마무리: 자동화보다 먼저 기준을 고정하기
Salesforce Flow Builder 업무 요청 라우팅 자동화의 핵심은 복잡한 기능을 많이 쓰는 것이 아니라, 팀이 합의한 배정 기준을 일관되게 실행하는 것입니다. 요청이 들어오는 지점, 조건 분기, 담당자 변경, 예외 확인 경로를 작게 나누면 첫 구축도 쉬워지고 운영 변경도 덜 부담스럽습니다. 최신 화면, 요금제, 기능 제공 범위는 바뀔 수 있으므로 실제 적용 전에는 공식 Salesforce 도움말과 현재 조직 설정을 다시 확인하세요.
