워크플로우 관리

제공 완료 확인

같은 사건이 반복돼도 중복 처리되지 않는지, 실패한 작업을 다시 처리한 결과가 맞는지 확인합니다.

다른 항목과의 구분

자동화 시스템의 동작을 검수합니다. 개별 자동화 설정마다 별도의 제공물을 만들지 않습니다.

워크플로우 실행 조건과 단계 설정하기

워크플로우의 정보 탭에서 실행 사건과 진입 필터를 설정하고, 흐름 캔버스에서 기능 단계와 판단 분기 및 반복 대상을 연결한 뒤 시험 실행으로 결과를 확인합니다.

시작 조건과 입력

자동화가 사용할 실행 주체의 권한과 시험용 원본 기록, 외부 발송 포함 여부를 먼저 확인하세요.

• 조직과 데이터 접근 권한 정하기: 자동화가 데이터를 읽거나 바꿀 때

커맨드 시퀀스

open "$entry_url" && snapshot -i
click "$workflow_row" && snapshot -i
click "$info_tab" && snapshot -i
click "$trigger_picker" && snapshot -i
click "$cron_option" && snapshot -i
fill "$schedule_input" "$schedule" && press 'Tab' && snapshot -i
click "$flow_tab" && snapshot -i
click "$step_node" && snapshot -i
get text body
# 외부 수행: 시험용 원본 이벤트를 한 번 발생시킵니다. 실제 고객 발송을 포함하는 설정은 시험 대상만 사용하세요.
open "$workflow_run_url" && snapshot -i
get text body

결과 확인

해당 workflow run과 step run에 의도한 결과가 있고 중복 실행이 없습니다.

중단 후 다시 시작하기

다시 시작할 때 같은 ID의 현재 값을 읽으세요. 이미 맞게 저장된 설정은 유지하고 다른 값만 수정합니다.

예약이 확정되었을 때 안내 메시지를 보내거나, 시작 시각이 지났는데도 방문하지 않은 예약을 찾아 후속 조치를 남기는 것처럼 반복되는 운영 업무는 워크플로우로 자동화할 수 있습니다. 워크플로우 상세 패널은 전체 실행 구조를 그래프 형태로 보여 주는 흐름 탭과 트리거 및 상태를 편집하는 정보 탭으로 구성됩니다.

이 문서는 워크플로우를 초안(draft) 상태로 두고 트리거와 진입 필터를 설정한 뒤, 흐름 캔버스에서 실행 단계와 AI 또는 규칙 기반 판단 단계를 연결하고 시험 사건으로 검증하는 방법을 안내합니다.

설정할 트리거 예시: 매일 오전 9시 스케줄(0 9 * * *) 또는 예약 상태가 확정으로 바뀔 때(db)

구성할 단계 예시: 대상 조회 또는 판단(workflows.decide) 후 조건에 맞는 후속 기능 실행

처음부터 운영 상태(active)로 두고 편집하면 미완성 단계가 실제 고객에게 실행될 수 있습니다. 시험 기록 한 건으로 실행 기록과 단계 결과를 끝까지 확인한 뒤에 상태를 활성으로 전환하세요.

흐름 탭과 정보 탭의 구성

왼쪽 메뉴에서 워크플로우를 열고 목록에서 워크플로우를 클릭하면 오른쪽 패널 상단에 흐름 탭과 정보 탭이 나타납니다.

실행 사건과 조건

정보 탭(또는 흐름 캔버스 맨 위의 트리거 카드 클릭)에서 워크플로우가 언제 시작될지 트리거를 선택합니다. 업무 성격에 따라 다음 네 가지 중 하나를 고르세요.

db 트리거를 선택하면 감시할 테이블(source_table)과 사건(source_event) 아래에 목록 화면과 동일한 필터(source_query) 편집기가 나타납니다. 필터 버튼을 눌러 예를 들어 상태: 확정 조건 칩을 추가하면, 예약이 새로 생성될 때 확정 상태이거나 이전 상태가 확정이 아니었다가 확정으로 새로 진입한 경우에만 워크플로우가 실행됩니다. 설정한 조건 칩은 흐름 탭의 트리거 카드 하단에도 그대로 표시됩니다.

실행 단계와 입력

흐름 탭으로 돌아와 오른쪽 위의 추가 또는 판단 버튼을 클릭해 단계를 구성합니다. 캔버스에서 단계 카드를 클릭하면 옆에 열리는 단계 상세 패널에서 다음 항목을 설정할 수 있습니다.

1. 일반 기능 단계와 목록 조회(*.list) 및 반복 실행(each)

1. 기능(feature) 선택: 단계가 실행할 작업(예: reservations.list, reservations.update, 템플릿 메시지 발송 등)을 선택합니다.
2. 목록 조회 조건 설정: 선택한 기능이 reservations.list나 customers.list 같은 목록 조회라면, 입력 영역에 전용 필터 칩 편집기(조회 조건 (where), 정렬 기준 (order), 최대 건수 (limit))가 나타납니다. 필터 버튼을 눌러 조회할 상태나 기간 조건을 칩으로 추가하세요.
3. 반복 대상(each) 연결: 앞선 조회 단계가 찾은 여러 기록을 하나씩 처리하려면 다음 단계의 each 입력란에 앞 단계의 행 배열 경로(예: ${steps.step_1.rows})를 지정합니다. each가 설정된 단계 카드는 캔버스에 ↻ ${steps.step_1.rows} 배지가 표시되며, 실행 시 각 항목을 ${item}으로 받아 건별로 단계 실행(step_runs)을 남깁니다.

2. 판단(workflows.decide) 단계와 조건 분기(when)

고객 문의 내용이나 기록 상태를 분류해 서로 다른 단계로 분기하려면 상단에서 판단 버튼을 눌러 판단 단계를 추가합니다.

1. 판단 대상(state)과 질문 키: 판단할 기준 데이터(예: 트리거 데이터 (${trigger}) 또는 반복 항목 (${item}))를 고르고 질문 키(예: urgency)를 입력합니다.
2. 질문 유형과 평가 방식:
   • 질문 유형은 선택형 (Choice), 예/아니오 (Boolean), 점수/단계 (Score), 테이블 필드 연결 중 하나를 선택합니다.
   • 평가 방식이 AI 추론이면 선택지 기준과 판단 지침을 문장으로 적고, 규칙 (Rules)이면 기준 테이블과 필터 칩 케이스별로 반환할 답을 지정합니다.
3. 후속 단계의 실행 조건(when) 연결: 판단 결과에 따라 실행할 후속 단계 카드를 클릭하고 실행 조건 (when)에서 조건 추가를 누릅니다. 조건 기준 데이터에서 앞선 판단 질문(예: 판단: 판단 1 - urgency)이나 트리거 데이터를 고른 뒤, 필터 칩으로 조건(예: 값: high)을 지정하세요. 설정을 마치면 흐름 캔버스의 두 단계 사이 연결선 위에 해당 조건 칩이 표시되어 분기 경로를 한눈에 볼 수 있습니다.

실행 권한

워크플로우는 이를 생성하거나 소유한 구성원(member)의 역할 권한 범위 안에서 실행됩니다. 단계에 지정한 기능(조회, 수정, 발송)이 소유 구성원의 역할에 허용되어 있는지 조직과 데이터 접근 권한에서 확인하세요.

프롬프트나 단계 설명에 권한을 허용한다는 문구를 적어도 실제 데이터베이스 접근 권한은 바뀌지 않습니다. 소유 구성원의 역할이 축소되거나 계정이 비활성화되면 워크플로우 실행이 거부될 수 있으므로 담당자 변경 시 함께 점검하세요.

중복 실행과 오류 처리

특히 heartbeat나 cron처럼 반복 실행되는 워크플로우에서는 이미 처리한 기록이 다음 주기에 다시 선택되지 않도록 조건을 설계해야 합니다.

1. 상태 전환으로 재진입 방지: 예를 들어 미확정 예약을 조회해 안내를 보냈다면, 후속 단계에서 예약 상태나 확인 필드를 함께 갱신해 다음 조회 조건에서 제외되게 만듭니다.
2. 외부 발송과 결제의 중복 방지: 메시지 발송, AI 아웃바운드 전화, 결제 요청처럼 고객에게 직접 전달되는 단계가 있다면 같은 원본 사건에 대해 이미 발송이나 결제가 완료되었는지 먼저 확인합니다.

시험 실행 확인

설정을 마쳤다면 실제 고객 전체에 적용하기 전에 합성 시험 기록 한 건으로 실행을 검증하세요.

1. 시험용 예약이나 고객 기록 한 건으로 트리거 조건을 만족시킵니다. 발송 단계가 포함된 경우 수신처가 시험용 연락처로 제한되어 있는지 반드시 확인하세요.
2. 왼쪽 메뉴에서 워크플로우 실행을 열어 방금 생성된 실행 기록의 상태가 성공(succeeded)인지 확인합니다.
3. 실행 기록을 클릭해 각 단계 실행(step_runs)의 입력과 출력, 판단 단계가 반환한 값(values), 분기 조건에 따라 건너뛴 단계(skipped)가 의도와 맞는지 대조합니다.
4. 같은 사건을 다시 발생시켰을 때 중복 실행이 일어나지 않는 것까지 확인한 뒤, 워크플로우 정보 탭에서 상태를 활성(active)으로 바꾸세요.

결과가 예상과 다를 때

기록을 수정했는데 db 트리거 워크플로우가 실행되지 않습니다

update 사건에 필터(source_query)가 설정되어 있으면, 수정 전에는 조건을 만족하지 않다가 수정 후에 조건을 만족하게 된 새 진입 순간에만 실행됩니다. 이미 상태: 확정이었던 예약의 메모만 수정한 경우에는 다시 실행되지 않는 것이 정상입니다. 또한 워크플로우의 상태가 초안이나 일시 중지가 아닌지 정보 탭에서 확인하세요.

흐름 캔버스에서 추가한 단계가 원하는 분기 아래에 연결되지 않습니다

캔버스의 연결선은 단계의 실행 조건(when), 반복 대상(each), 입력(input)에서 참조하는 앞 단계(${steps.<이름>} 또는 판단 질문)를 기준으로 자동 배치됩니다. 특정 판단 단계 아래로 분기시키려면 후속 단계의 실행 조건 (when)에서 해당 판단 질문을 조건 기준 데이터로 선택하세요.

반복 실행(each) 단계가 0건으로 건너뛰어집니다

앞선 조회 단계(*.list)의 실행 결과(step_runs)를 열어 실제로 조회된 행(rows)이 있는지 먼저 확인하세요. 또한 each 입력란에 적은 단계 슬러그 이름(예: ${steps.step_1.rows})이 앞 단계의 이름과 정확히 일치하는지 대조합니다.

실행 기록에 권한 오류가 나타납니다

워크플로우 소유 구성원의 역할에 해당 단계의 기능(예: reservations.update 또는 deliveries.insert) 권한이 있는지 확인하세요. 권한을 수정한 뒤에는 실패 단계 확인과 복구 절차에 따라 안전하게 재개합니다.

워크플로우 실행 결과와 실패 단계 확인하기

워크플로우 실행과 단계 실행 기록에서 실패 지점과 이미 완료된 외부 효과를 구분하고, 중복 발송이나 중복 결제 없이 원인을 수정해 복구합니다.

시작 조건과 입력

중단되거나 실패한 워크플로우 실행 ID와 첫 실패 단계, 연결된 원본 기록 ID를 확인하세요.

커맨드 시퀀스

open "$entry_url" && snapshot -i
click "$workflow_run" && snapshot -i
get text body
open "$cause_record_url" && snapshot -i
get text body
# 외부 수행: 담당자가 원인을 수정한 후 지원되는 복구 경로로 재개합니다. 이미 끝난 발송과 결제를 반복하지 않습니다.
open "$workflow_run_url" && snapshot -i
get text body

결과 확인

기존 성공 작업을 중복 실행하지 않았고 복구 결과가 원래 사건에 연결됩니다.

중단 후 다시 시작하기

접수 ID와 원래 요청의 처리 결과를 먼저 확인하세요. 결과를 확인할 수 없다면 같은 요청을 새로 제출하지 않습니다.

워크플로우가 활성 상태로 설정되어 있더라도, 고객 연락처가 비어 있거나 외부 발송 계정의 권한이 만료되면 개별 실행이 실패(failed)할 수 있습니다. 이때 원인을 확인하지 않고 전체 워크플로우를 처음부터 다시 실행하면, 앞 단계에서 이미 성공한 메시지 발송이나 상태 변경이 같은 고객에게 두 번 실행될 위험이 있습니다.

이 문서는 워크플로우 실행에서 실패한 실행과 단계별 결과를 차례대로 읽고, 이미 완료된 작업을 제외한 채 안전하게 원인을 복구하는 절차를 안내합니다.

점검할 실행 상태: 실패 (failed)

확인할 핵심 기준: 첫 실패 단계 이전의 성공(succeeded) 단계에 외부 발송이나 결제가 포함되어 있는지 여부

실행 기록 찾기

왼쪽 메뉴에서 워크플로우 실행을 엽니다. 목록에서 워크플로우 이름, 상태(대기, 실행 중, 성공, 실패), 시작 시각을 확인하고 점검할 실행 행을 클릭하세요.

워크플로우 목록에서 상태가 활성이라고 표시되는 것은 앞으로 사건을 감지하겠다는 설정일 뿐, 지난 실행이 성공했다는 뜻이 아닙니다. 실제 성공 여부는 반드시 워크플로우 실행 기록에서 확인하세요.

단계별 입력과 결과

실패한 워크플로우 실행의 상세 패널에서 연결된 단계 실행(step_runs) 목록을 순서(position)대로 확인합니다.

1. 첫 실패 단계 이전의 성공 단계 점검: 1번 단계부터 실패 단계 직전까지 이미 succeeded로 끝난 단계가 무엇인지 확인하세요. 만약 앞 단계에서 메시지 발송이나 결제 요청이 이미 성공했다면, 그 작업은 다시 실행해서는 안 됩니다.
2. 판단(workflows.decide) 및 건너뜀(skipped) 확인: 단계 상태가 skipped라면 오류가 아니라 실행 조건(when)이 맞지 않아 의도적으로 건너뛴 것입니다. 앞선 판단 단계의 출력(values)을 열어 어떤 값으로 분류되었는지 확인하세요.
3. 실패 원인 분류: failed 단계의 입력(input)과 오류 메시지(error)를 읽고 다음 세 가지 중 어디에 해당하는지 구분합니다.
   • 원본 데이터 누락: 고객 전화번호 누락, 필수 사용자 필드 비어 있음, 취소된 예약 참조
   • 실행 권한 부족: 워크플로우 소유 구성원의 역할에 해당 기능 권한이 없음
   • 외부 채널 또는 계정 오류: 발송 계정의 심사 미승인, 수신 거부 고객, 외부 연동 토큰 만료

재실행 조건

오류 원인을 찾았다면 원본 기록($cause_record_url)이나 권한 설정을 먼저 수정한 뒤 복구 범위를 정하세요. 모든 화면에 전체 재실행 버튼이 있다고 가정하거나, 무작정 트리거 사건을 다시 일으키지 마세요.

1. 조회나 판단 단계에서 실패한 경우 (외부 부작용 없음): 아직 기록 변경이나 외부 발송이 일어나지 않았으므로, 원본 데이터의 누락된 값을 채우거나 조건을 고친 뒤 다음 스케줄 주기나 지원되는 실행 경로로 재개할 수 있습니다.
2. 발송이나 수정 이후 후속 단계에서 실패한 경우 (부분 완료): 이미 완료된 발송을 반복하지 않도록, 실패한 마지막 작업(예: 예약 메모 갱신이나 후속 담당자 요청)만 해당 화면에서 직접 처리하거나 미처리 대상만 고르는 조건으로 실행하세요.
3. 반복 실패 시 일시 중지: 외부 계정 장애나 잘못된 필터 조건 때문에 실패가 계속 발생한다면, 먼저 워크플로우 정보 탭에서 상태를 일시 중지(paused)로 바꾼 뒤 조건을 수정하세요.

복구 후 결과

원인을 수정하고 후속 처리를 마쳤다면 다음 세 가지를 대조해 복구를 마무리합니다.

1. 원본 기록 상태: 대상 고객이나 예약, 결제 기록이 의도한 최종 상태로 반영되었는지 확인합니다.
2. 발송 및 결제 결과: 메시지나 전화 발송이 포함된 작업이라면 발송 기록(deliveries 또는 calls)에서 실제 1회만 전달되었고 중복 발송이 없는지 확인합니다.
3. 실행 이력 보존: 장애 원인을 추적할 수 있도록 원래 실패한 실행 ID와 복구 후 새로 생성된 실행 ID를 함께 확인하고 기록을 임의로 삭제하지 마세요.

결과가 예상과 다를 때

워크플로우 실행은 성공(succeeded)인데 특정 단계가 실행되지 않았습니다

해당 단계 실행(step_runs)의 상태가 skipped인지 확인하세요. 단계에 실행 조건(when)이 걸려 있으면 조건을 만족하지 않을 때 오류 없이 건너뛰고 전체 워크플로우 실행은 성공으로 끝납니다. 조건 기준 데이터와 앞선 판단 단계의 출력 값을 대조하세요.

원인을 고쳤는데 다음 주기에도 같은 기록이 계속 실패합니다

반복 조회(heartbeat 또는 cron)가 아직 실패 기록을 계속 선택하고 있는지, 아니면 실제로 수정한 고객이나 예약 행이 다른 중복 행이었는지 원본 ID를 대조하세요.

발송 단계는 성공했는데 고객이 메시지를 받지 못했습니다

단계 실행의 succeeded는 발송 요청 접수가 완료되었다는 뜻입니다. 실제 단말 도달 여부나 수신 거부, 채널 심사 상태는 메시지 전달 결과 확인 또는 해당 발송 기록에서 요청 ID로 확인하세요.