Flow Designer로 ITSM Incident 자동 라우팅 — assignment·알림·설문 3가지

개요

이전 글에서 정리한 Incident state 모델(New → In Progress → Resolved → Closed) 위에 자동화 3가지를 얹는다. (1) Incident 생성 시 Category/Priority 조합으로 assignment_group 자동 할당, (2) On Hold 진입 시 caller에게 이메일 알림, (3) Resolved 전환 시 만족도 설문 자동 트리거. 세 가지 모두 Flow Designer만으로 구현하며, OOTB(Out-of-the-Box, 기본 제공) 기준으로 설명한다.

OOTB 기준 설명입니다. 인스턴스/플러그인 활성화 상태에 따라 액션명·설정 화면이 다를 수 있습니다.

---

1. Flow Designer 빠른 정복

Flow Designer는 코드 없이 자동화를 구성하는 로우코드 엔진이다. 본격적인 시나리오에 들어가기 전에 핵심 구성 요소 4가지를 짚고 넘어간다.

구성 요소	역할	대표 예시
Trigger	Flow를 시작하는 조건. 레코드 이벤트·스케줄·카탈로그 제출 등	Record Created, Record Updated
Action	단일 작업 단위. 플랫폼이 제공하는 OOTB 블록	Update Record, Send Email, Trigger Survey
SubFlow	여러 Action을 묶어 재사용하는 하위 플로우	공통 알림 패키지, 승인 흐름
Script	GlideRecord·GlideSystem 등 서버 스크립트가 필요할 때	복잡한 조건 계산, 동적 필드 조합

Trigger와 Action만으로 대부분의 단순 자동화는 해결된다. SubFlow는 동일한 Action 묶음을 2개 이상 Flow에서 쓸 때 꺼내고, Script는 로우코드 범위를 벗어나는 로직이 생길 때 최후 수단으로 사용한다.

---

2. 시나리오 1: Assignment Group 자동 할당

Incident가 생성될 때 category와 priority 값을 읽어 적합한 assignment_group을 자동으로 채운다. 담당자가 매번 수동으로 그룹을 선택하는 반복 작업을 없애는 가장 기본적인 자동화다.

Flow 구성 요약

1. Trigger — Record Created (테이블: incident)
2. Condition — category IS network AND priority IS 1 - Critical
3. Action — Update Record → assignment_group 필드를 대상 그룹으로 set

조건 분기는 Flow Designer의 If/Else 블록으로 여러 Category를 처리할 수 있다. 각 분기마다 Update Record 액션을 두어 그룹을 다르게 설정한다.

assignment_group set

실무 팁 — Update Record 액션에서 필드를 set할 때 assignment_group은 Reference 타입이라 그룹의 sys_id를 넣어야 한다. Flow Designer의 Data Pill Picker에서 그룹명으로 검색해 직접 선택하면 자동으로 sys_id로 바인딩된다. 직접 문자열로 적으면 동작하지 않으니 주의하자.

---

3. 시나리오 2: On Hold 진입 시 Caller 알림

Incident가 On Hold 상태로 전환되면 hold_reason 값을 포함해 caller에게 이메일을 자동 발송한다. 담당자가 직접 이메일을 쓰지 않아도 고객이 상황을 인지할 수 있게 한다.

Flow 구성 요약

1. Trigger — Record Updated (테이블: incident)
2. Condition — state changed to 3 (On Hold)
3. Action — Send Email → 수신자: caller_id (Opened by)

Record Updated 트리거에서 “Field changes to value” 필터를 사용하면 incident_state = 3으로 변경된 경우만 Flow가 실행된다. 전체 업데이트마다 발동하지 않도록 조건을 좁히는 것이 중요하다.

OOTB Send Email 액션은 일반적으로 Notification 레코드를 거치지 않고 즉시 발송하는 형태로 동작한다. 다만 인스턴스에 따라 “Send Notification” 같은 변형 액션이 OOTB로 함께 제공되므로, 액션 팔레트에서 정확한 명칭을 먼저 확인하는 편이 안전하다. 이메일 본문은 액션의 “Message” 필드에서 Data Pill로 ${trigger.current.number}, ${trigger.current.hold_reason} 같은 동적 값을 끼워넣을 수 있다.

---

4. 시나리오 3: Resolved 시 만족도 설문

Incident가 Resolved 상태로 전환되면 caller에게 만족도 설문을 자동으로 트리거한다. 수동으로 설문 링크를 보내는 과정을 없앤다.

Flow 구성 요약

1. Trigger — Record Updated (테이블: incident)
2. Condition — state changed to 6 (Resolved)
3. Action — Trigger Survey → 대상 설문 선택, 수신자: caller

Trigger Survey 액션은 OOTB Survey 플러그인이 활성화된 인스턴스에서만 사용할 수 있다 (plugin ID는 인스턴스/버전에 따라 com.snc.survey 계열로 명칭이 상이하다). 플러그인이 비활성화된 경우 액션 팔레트에 “Trigger Survey”가 표시되지 않는다. 활성화 여부는 System Definition > Plugins에서 확인하자.

실무 팁 — Resolved 전환 후 일정 시간(예: 1시간)이 지난 뒤 설문을 보내고 싶다면, Flow에 Wait 액션(또는 Wait for Condition 블록)을 추가해 지연 발송을 구성할 수 있다. 바로 발송하면 담당자가 Resolved로 눌러놓고 바로 재오픈하는 경우에도 설문이 날아가므로, 짧은 지연을 두는 편이 실무에서 더 자연스럽다.

---

5. 검증·디버깅

Flow를 만든 뒤 실제로 동작하는지 확인하는 방법과, 흔히 마주치는 실패 원인을 정리한다.

실행 로그 확인 경로

Flow Designer > Operations > Flow Executions

또는 직접 테이블(sn_flow_designer.flow_execution)로 접근해도 된다. 각 실행 레코드에는 트리거 시점, 각 Step의 입출력, 오류 메시지가 기록된다. Flow가 발동하지 않는 것처럼 보일 때 여기서 먼저 확인하자.

흔한 실패 원인 4가지

Flow Executions 로그를 보면 각 Step의 Input과 Output이 JSON 형태로 남는다. “Step failed” 표시가 보이면 해당 Step을 펼쳐 오류 메시지를 읽는 것이 디버깅의 첫 단계다.

디버깅 첫 5분 체크리스트

Flow가 의도대로 실행되지 않을 때 위 4가지 원인을 처음부터 다 의심하지 말고, 다음 순서로 5분 안에 1차 진단을 끝내자.

1. Flow가 활성화되어 있는가 — Flow Designer 상단 토글이 “Active” 상태인지 먼저 확인. 저장만 하고 활성화를 깜빡하는 경우가 의외로 많다.
2. Flow Executions에 실행 레코드가 남았는가 — 레코드 자체가 없으면 Trigger 조건 단계에서 막힌 것이다. 레코드는 있는데 실패면 Step 단계로 넘어가자.
3. 첫 Step의 Input이 비어 있지 않은가 — Trigger에서 전달된 값이 정상이면 condition·action 진입은 했다는 뜻이다.
4. Run as 계정이 대상 테이블 write 권한을 가졌는가 — 권한 부족은 조용히 실패한다 (실패 원인 2번과 동일).
5. 같은 Trigger를 쓰는 다른 Flow나 BR이 있는가 — assignment_group 등 같은 필드를 건드리는 경쟁자가 있으면 순서/덮어쓰기 충돌이 생긴다.

이 다섯 가지를 체크하고도 원인이 명확하지 않을 때 위 카드의 4가지 실패 원인을 본격적으로 파고들어도 늦지 않다.

---

마무리

이전 글 Incident state 모델 이 “무엇을 자동화할 것인가”의 지도라면, 이번 글의 세 가지 시나리오는 그 지도 위에 실제 경로를 그리는 작업이다. 세 Flow 모두 Trigger + Condition + Action 3개 블록의 조합이라는 점을 확인했다. 다음 글 Flow Designer Action vs SubFlow vs Script 에서 이 기초 위에 빌딩 블록 결정 트리를 다룬다. 복잡도가 올라갈수록 이 선택이 유지보수성을 가른다.