Power Automate로 승인 흐름 만들기 ── 종이와 메일 결재·신청을 전자화하다

「결재서를 인쇄해서 도장을 찍고, 옆 부서로 돌리고, 돌아오는 데 일주일」「Excel 신청서를 메일에 첨부해 보내고, 승인은 답장 메일의 ‘확인했습니다’」. Microsoft 365를 도입한 회사로부터 이런 신청·승인 업무를 어떻게든 하고 싶다는 상담을 자주 받습니다.

Power Automate에는 승인(Approvals)이라는 전용 기능이 있어, Teams나 Outlook에서 승인 버튼을 누르는 것만으로 끝나는 승인 흐름을, 추가 비용 없이 라이선스 범위 안에서 구성할 수 있는 경우가 많습니다. 다만 첫 흐름이 동작하는 것과 업무로서 안심하고 돌릴 수 있는 것 사이에는 거리가 있습니다. 승인 기록은 어디에 남는지, 승인자가 방치하면 어떻게 되는지, 담당자가 퇴사하면 흐름은 누가 고치는지. 이 글에서는 승인 흐름의 기본 부품부터, 실무에서 걸리기 쉬운 설계 포인트, 그리고 Power Automate로 해야 할 범위의 경계선까지 정리합니다.

1. 먼저 결론

• Power Automate의 승인은 ‘승인을 시작하고 대기’ 작업이 기본입니다. 승인 종류는 ‘모든 사람의 승인 필요’, ‘최초 응답’, ‘커스텀 응답(전원/1명)’, ‘순차 승인’의 5가지 중에서 선택할 수 있습니다.¹
• 승인자는 Teams・Outlook・Power Automate 포털・모바일 앱 어디에서든 응답할 수 있습니다. 승인만을 위해 새로운 화면 사용법을 익힐 필요는 거의 없습니다.²³
• 신청 접수 창구는 Microsoft Forms / SharePoint 목록 / Teams의 승인 앱 3가지가 현실적입니다. 나중에 목록화·집계하고 싶다면 SharePoint 목록을 축으로 삼는 것이 정석입니다.
• 흐름의 실행 이력은 기본적으로 28일만 보이고, 1회 실행은 최장 30일에 타임아웃됩니다. 승인의 증적을 실행 이력에 의존하지 않고, 결과를 SharePoint 목록 등에 다시 쓰는 설계를 처음부터 넣어 둡니다.⁴⁵
• 흐름 소유자의 퇴사·이동은 승인 흐름 최대의 운영 리스크입니다. 공동 소유자 설정과 연결 처리를, 가동을 시작한 날 중에 끝내 둡니다.⁶
• 조건 분기가 많은 다단계 승인, 대리 결재나 감사 요건이 엄격한 결재 규정을 그대로 구현하려 하면, Power Automate로는 유지보수가 불가능해집니다. 그런 경우는 워크플로 시스템이나 수탁 개발의 영역입니다.

2. 종이·메일 결재의 무엇이 문제인가

종이 결재서나 메일 첨부 Excel의 승인이 힘든 것은, 수고 그 자체보다도 ‘상태가 보이지 않는다’는 점입니다. 상담을 받다 보면 공통적으로 나오는 것은 대체로 다음 3가지입니다.

• 지금 어디서 멈춰 있는지 알 수 없다. 결재서가 누구의 책상 위에 있는지, 메일이 어느 받은편지함에 묻혀 있는지, 신청한 본인에게는 보이지 않습니다. 재촉은 구두나 전화가 되고, 재촉받는 쪽도 기분이 좋지 않습니다.
• 기록이 흩어진다. 승인의 증적이 종이 캐비닛과 개인 메일함에 분산됩니다. 감사나 나중의 조회로 ‘그 신청, 누가 언제 승인했는지’를 조사하려면 사람의 메일함을 뒤지게 됩니다. 담당자가 퇴사하면 메일함째로 사라집니다.
• 반려를 추적할 수 없다. 반려나 수정 요청이 구두·메일로 이루어지면, 어느 버전의 신청서에 대한 지적이었는지가 섞입니다. 수정판을 다시 보내면, 또 처음부터 회람입니다.

이것들은 ‘신청의 상태와 기록을 한 곳에 모으는’ 것으로 거의 해결됩니다. 그리고 Microsoft 365를 도입했다면, 그 보관 장소(SharePoint)와 알림 경로(Teams/Outlook)와 자동화(Power Automate)는 이미 손에 있습니다.

3. Power Automate 승인의 기본 부품

‘승인을 시작하고 대기’ 작업

승인 흐름의 중심은 승인(Approvals) 커넥터의 ‘승인을 시작하고 대기(Start and wait for an approval)’ 작업입니다. 승인 요청의 제목·상세·승인자를 지정하면, 흐름은 그 지점에서 정지하고 승인자의 응답을 기다린 뒤 다음 작업으로 넘어갑니다.¹

승인 종류는 5가지가 있습니다.¹

커스텀 응답을 사용하면, ‘승인’, ‘거부’의 2택이 아니라 ‘승인’, ‘반려’, ‘보류’ 같은 선택지를 정의할 수 있습니다. 뒤에서 설명할 반려 루프의 부품이 됩니다.

또한 승인 기능을 사용하려면 Microsoft Dataverse 데이터베이스가 필요합니다. 승인 요청과 응답 레코드는 Dataverse에 저장되며, 기본 환경에서는 승인 흐름을 처음 만들 때 자동으로 준비되므로, 보통은 의식하지 않고 사용을 시작할 수 있습니다. 승인 커넥터는 표준 커넥터이므로, 표준 커넥터를 사용할 수 있는 라이선스(Office 365 등)로 승인 흐름을 만들 수 있습니다.¹

Dataverse란 ── 어디서 신경 써야 하는가

여기서 처음 등장한 Dataverse(데이터버스)는 Power Platform 공통의 데이터 저장 기반입니다. 대략적으로 말하면, 자사의 Microsoft 365 테넌트 안에 준비되는 클라우드 데이터베이스로, Power Apps 앱이나 흐름이 다루는 데이터의 보관 장소로 사용됩니다. 승인 기능은 이 위에 얹혀 있어, ‘누구에게・언제 승인을 의뢰하고, 누가 어떻게 응답했는지’는 Dataverse의 테이블에 레코드로 기록됩니다.

일상적인 작성·운영에서 Dataverse를 의식할 필요는 거의 없지만, 다음 3가지 장면에서만 얼굴을 내밉니다.

• 새 환경에서 승인을 처음 사용할 때. 기본 환경이라면 자동으로 준비되지만, 부서용으로 새로 만든 환경에서는 Dataverse 데이터베이스의 유무를 확인할 필요가 있습니다.¹
• 승인 이력이 쌓였을 때. 승인 이력은 환경의 저장 용량을 소비하며, 용량 사정으로 삭제 대상이 될 수 있습니다. 증적을 실행 이력에도 Dataverse에도 의존하지 않는 이유가 여기에 있습니다(다음 장).⁷
• 승인 레코드를 직접 읽고 쓰고 싶어졌을 때. Dataverse 커넥터로 테이블을 직접 다루는 구성으로 하면, 그 커넥터는 프리미엄 등급으로 분류되므로 추가 라이선스 이야기가 발생합니다.⁸

즉 ‘승인을 평범하게 사용하는 정도라면 라이선스 추가 없음, Dataverse 자체를 건드리기 시작하면 이야기가 달라진다’는 경계선입니다.

승인자는 어디서 응답하는가

승인자에게는 메일과 Power Automate 모바일 앱으로 승인 요청이 도착합니다.³ Outlook에서는 정리된 형태의 승인 메일이 도착하고, 그곳에서 응답할 수 있습니다.⁹ 개인 사용자 앞으로 보낸 승인은 Teams에도 알림이 가서, Teams 채팅이나 승인 앱에서 승인·거부·코멘트 입력을 할 수 있습니다.² ‘승인을 위해 전용 사이트에 로그인해야 한다’는 장벽이 없다는 점이, 승인 흐름 정착의 가장 큰 원동력이 됩니다.

한 가지 주의할 점이 있습니다. 승인 대상을 Microsoft 365 그룹으로 하면 Teams 알림이 전송되지 않습니다. Teams 알림이 도착하는 것은 개인 사용자 앞으로 보낸 승인뿐입니다.¹⁰

흐름 전체 구조

구매 신청을 예로 들면, 전체는 이런 형태가 됩니다.

flowchart TD
    Submit[신청자가 입력<br/>Forms 제출 / SharePoint 목록에 등록] --> Trigger[클라우드 플로우 시작<br/>새 응답・항목 추가 트리거]
    Trigger --> Record[신청 내용을 SharePoint 목록에 기록<br/>상태: 승인 대기]
    Record --> Approval[승인을 시작하고 대기<br/>승인자에게 요청 전송]
    Approval -- Teams / Outlook / 모바일 --> Response{응답}
    Response -- 승인 --> UpdateOK[목록의 상태를 '승인 완료'로 업데이트<br/>승인자・일시・코멘트를 열에 기록]
    Response -- 거부/반려 --> UpdateNG[상태를 '반려'로 업데이트<br/>신청자에게 사유 통지]
    Response -- 타임아웃 --> Remind[독촉 알림 / 에스컬레이션]
    UpdateOK --> NotifyOK[신청자에게 결과 통지]
    UpdateNG --> Resubmit[신청자가 수정하여 재신청]
    Resubmit -- 트리거 조건으로<br/>'재신청'만 시작 --> Trigger

포인트는 승인 작업의 앞뒤에 ‘기록’ 단계를 끼워 넣은 것입니다. 이유는 5장에서 설명합니다.

4. 신청 접수 창구를 어떻게 설계하는가

승인 흐름의 사용 편의성은 승인 쪽보다도 신청 쪽 입력 접수 창구로 결정됩니다. 현실적인 선택지는 3가지입니다.

판단 기준은 다음과 같습니다.

• 어쨌든 그때그때의 승인만 전자화하고 싶다면, 흐름을 만들지 않아도 Teams의 승인 앱으로 충분합니다. 승인 앱은 채팅에서 그 자리에서 승인 요청을 보낼 수 있는 기능으로, Power Automate 기반 위에서 동작하지만 흐름 작성은 필요 없습니다.¹¹
• 신청서 대체라면, Forms를 접수 창구로 하고 응답을 흐름으로 받아 승인으로 돌리는 것이 가장 빠릅니다. Forms의 응답 내용을 승인 요청에 삽입하는 템플릿도 준비되어 있습니다.¹³
• 신청 대장으로 관리하고 싶다면, SharePoint 목록을 축으로 합니다. Forms를 입구로 하는 경우에도, 흐름 맨 앞에서 응답을 목록에 전기해 두면, 상태 열(승인 대기/승인 완료/반려)과 보기로 ‘지금 어디서 멈춰 있는지’가 누구에게나 보이게 됩니다. 서두에서 언급한 종이·메일 결재의 과제에 대한 답은, 사실상 여기에 있습니다.

소규모로 시작한다면 ‘Forms로 받아 SharePoint 목록에 기록하고, 승인 결과도 목록에 다시 쓰는’ 구성이 입력의 간편함과 대장 관리를 동시에 얻을 수 있어 다루기 쉽습니다.

5. 실무에서 효과적인 설계 포인트

승인 기록을 어디에 남길 것인가 ── 실행 이력에 의존하지 않는다

가장 중요한 설계 판단입니다. 흐름의 실행 이력은 기본적으로 28일만 표시됩니다.⁴ 솔루션에 포함시킨 흐름이라면 실행 이력 메타데이터를 Dataverse에 남길 수 있지만, 이쪽도 기본 보존 기간은 28일이며 관리자가 보존 기간을 조정하는 구조입니다.¹⁴

즉 ‘누가 언제 승인했는지’를 실행 이력으로 나중에 조사하는 운영은 한 달 만에 무너집니다. 승인 요청·응답 레코드 자체는 Dataverse에 저장되지만¹⁵, 감사 대응이나 일상적인 조회 때마다 Dataverse 테이블을 들여다보는 것은 현실적이지 않고, 승인 이력은 환경의 저장 용량을 소비하기 때문에 용량 사정으로 삭제 대상이 되기도 합니다.⁷

실무에서는 승인 작업 직후에, 결과・승인자・응답 일시・코멘트를 SharePoint 목록의 열에 다시 쓰는 단계를 반드시 넣습니다. ‘승인을 시작하고 대기’ 작업은 응답・승인자・코멘트를 출력으로 반환하므로¹⁵, 그것을 그대로 열에 기록하기만 하면 됩니다. 신청과 승인 기록이 같은 목록의 같은 행에 맞춰지고, 보존 기간은 목록의 운영 방식에 따라 몇 년이든 유지할 수 있습니다.

한 가지만 주의할 점이 있습니다. ‘모든 사람의 승인 필요’나 커스텀 응답(전원)과 같은 복수 승인자 종류에서는, 응답(Responses)이 인원수만큼의 배열로 반환됩니다.³ 이것을 하나의 열 세트에 순서대로 덮어쓰면 마지막 응답만 남으므로, 복수 승인자의 기록은 응답마다 이력용 목록에 한 줄씩 추가하거나, 전원의 응답을 하나의 텍스트로 정리한 뒤 열에 기록하는 형태로 합니다.

타임아웃과 리마인더 ── ‘기한 없는 승인’은 만들 수 없다

클라우드 플로우 1회 실행은 최장 30일입니다. 이 30일에는 승인 대기와 같은 보류 중인 단계도 포함되며, 30일이 지나면 보류 중인 단계는 타임아웃됩니다.⁵ 승인자가 방치하면, 흐름은 조용히 실패로 끝납니다. 이것을 모르고 운영을 시작하면, ‘신청했는데 아무 일도 일어나지 않는다’는 가장 신뢰를 해치는 사고가 일어납니다.

대책은 2단계입니다.

1. 승인 작업에 명시적인 타임아웃을 설정한다. 작업 설정에서 ISO 8601 형식(예: P3D로 3일)의 타임아웃을 지정하고, 실행 조건 구성에서 ‘타임아웃된 경우’ 분기를 마련합니다.¹⁶ 여기서 주의할 점은, 타임아웃된 시점에 원래의 승인 대기는 종료되어 있다는 것입니다. 그 이후에 승인자가 응답해도, 이 실행의 후속 단계(결과 다시 쓰기 등)에는 흘러가지 않습니다. 즉 타임아웃 분기는 ‘계속 기다리면서 독촉하는’ 장소가 아니라, ‘일단 끊고 다음 수를 두는’ 장소입니다. 독촉하려면 타임아웃 분기에서 알림을 보낸 뒤 새 승인 요청을 다시 보냅니다.
2. 30일을 넘길 가능성이 있는 승인은 흐름을 2개로 나눈다. ‘승인 만들기(v2)’ 작업으로 승인 요청만 보내고 첫 번째 흐름은 종료하며, 응답에 대한 후속 처리는 별도 흐름에서 수행하는 구성이 공식적으로 안내되고 있습니다. 승인 레코드는 Dataverse에 있으므로, 원래 흐름의 실행이 끝나도 응답은 처리할 수 있습니다. 대기를 끊지 않고 유연한 독촉을 짜고 싶은 경우에도, 이 2단 구성 쪽이 자연스럽게 만들어집니다.¹⁷ 또한 두 번째 흐름의 시작 방법에는 설계의 여지가 있으며, 승인 테이블의 변경을 Dataverse 커넥터의 트리거로 직접 받는 구성으로 할 경우, Dataverse 커넥터가 프리미엄 라이선스 대상이 되는 점에 주의해 주세요(승인 커넥터 자체의 작업은 표준 범위입니다¹).⁸

타임아웃과 분기 설정 절차

글로는 이해하기 어려운 부분이므로, 디자이너에서의 조작을 순서대로 적어 둡니다.

1. ‘승인을 시작하고 대기’ 작업 카드 오른쪽 위의 ‘…’에서 설정(Settings) 을 열고, 타임아웃(Timeout) 란에 ISO 8601 형식의 기간을 입력합니다. 3일이면 P3D, 12시간이면 PT12H입니다. 비워 두면 흐름 실행 기간의 상한(30일)까지 기다립니다.
2. 승인 작업 아래에, 타임아웃되었을 때 하고 싶은 처리(독촉 알림 등)의 작업을 하나 배치합니다.
3. 그 작업의 카드 오른쪽 위 ‘…’에서 실행 조건 구성(Configure run after) 을 열고, 바로 앞의 승인 작업에 대해 ‘타임아웃되었습니다‘에만 체크합니다. 기본값은 ‘정상적으로 완료되었습니다’이므로, 이것을 해제하는 것을 잊지 마세요.
4. 승인된 경우의 처리(결과 다시 쓰기・신청자에게 통지)는 승인 작업으로부터의 또 다른 분기로 나란히 배치하고, 이쪽은 ‘정상적으로 완료되었습니다’ 그대로 둡니다. 실행 조건 구성으로 가지를 나누면, 디자이너에서는 2개의 분기가 나란히 표시됩니다.

‘3일에 독촉, 7일에 상급자에게’를 만드는 방법

가장 만들고 싶은 부분이 여기라고 생각하므로, 직렬 2~3단 구성을 구체적으로 보여 드립니다. 1단계에서 3일을 기다리고, 무응답이면 독촉하여 같은 상사에게 다시 보내고, 다시 4일이 지나면 상급자에게 넘기는 형태입니다.

flowchart TD
    A1[승인을 시작하고 대기 1단계<br/>승인자: 직속 상사<br/>설정 타임아웃 P3D] --> Q1{응답이 있었나}
    Q1 -- 승인・거부 --> Rec[결과를 SharePoint 목록에 다시 쓰기<br/>신청자에게 통지]
    Q1 -- 3일간 무응답 --> R1[독촉 알림 전송<br/>실행 조건 구성: 타임아웃되었습니다]
    R1 --> A2[승인을 시작하고 대기 2단계<br/>승인자: 같은 상사<br/>설정 타임아웃 P4D]
    A2 --> Q2{응답이 있었나}
    Q2 -- 승인・거부 --> Rec
    Q2 -- 다시 4일간 무응답 --> R2[에스컬레이션 알림 전송<br/>실행 조건 구성: 타임아웃되었습니다]
    R2 --> A3[승인을 시작하고 대기 3단계<br/>승인자: 상급자<br/>타임아웃 설정 없음]
    A3 --> Rec

만들 때 포인트는 3가지입니다.

• 2단계・3단계는 ‘새로운 승인 요청’입니다. 1단계 요청은 3일 만에 종료되었으므로, 승인자의 Teams나 Outlook에는 별개의 요청으로 도착합니다. 요청 제목에 ‘【독촉】’, ‘【에스컬레이션】’을 붙이고, 신청일과 경과일수를 본문에 넣어 두면 받는 쪽이 상황을 이해할 수 있습니다.
• 타임아웃 합계를 흐름의 30일 안에 맞춥니다. 위 예시는 1단계 3일 + 2단계 4일로 7일을 사용하므로, 3단계에 남는 것은 23일이 채 안 됩니다. 단계 수를 늘릴수록 3단계의 여유가 줄어듭니다.
• 결과 다시 쓰기를 한 곳에 모으고 싶다면 변수를 사용합니다. 승인 결과는 단계마다 다른 작업의 출력이 되므로, 그대로 적으면 다시 쓰기 단계가 3곳으로 늘어납니다. 흐름 맨 앞에서 문자열 변수(예: 승인결과)와 승인자를 초기화해 두고, 각 단계의 승인 작업 직후에 ‘변수 설정’을 하나씩 배치한 뒤, 마지막에 한꺼번에 한 번만 목록에 다시 쓰면 이후 유지보수가 편해집니다.

‘타임아웃→독촉→재요청’을 Do until 루프로 감싸는 형태도 만들 수 있지만, Do until에는 루프 자체의 상한(기본 60회・1시간)이 별도로 있어, 승인 대기와 같은 장시간 작업을 안에 넣는 경우는 ‘제한 변경’으로 루프의 타임아웃을 명시적으로 늘리지 않으면, 1회차 다음 2회차 이후가 시작되지 않습니다.⁵¹⁸ 이 ‘제한 변경(Change limits)’은 Do until 작업 카드 안에 있는 링크로, 열면 카운트(Count) 와 타임아웃(Timeout) 2가지를 지정할 수 있습니다. 카운트는 반복 횟수(기본 60), 타임아웃은 루프 전체의 제한 시간을 ISO 8601로 적는 란(기본 PT1H)입니다. 3일 기다리는 승인을 3회 반복시키고 싶다면, 카운트를 3, 타임아웃을 P10D처럼 ‘예상되는 반복 시간 합계보다 긴 값’으로 합니다. 다만 여기를 늘려도 흐름 전체의 30일은 늘어나지 않습니다.

중소기업의 결재라면, 우선 ‘3일에 독촉, 7일에 상사에게 에스컬레이션’ 같은 사내 규칙을 정하고, 이를 재요청 루프 또는 2단 구성으로 구현하는 것이 현실적입니다.

부재중 재할당

승인자가 장기 부재인 경우는 반드시 일어납니다. 승인 요청을 받은 본인은 Power Automate 포털의 승인 목록에서 요청을 다른 사람에게 재할당(Reassign)할 수 있습니다. 한편, 요청을 보낸 쪽에서의 재정비는 요청 취소와 승인자 변경・재실행이라는 절차가 됩니다.⁹ 주의할 점은, 이 글과 같은 자동 시작 흐름에서는 이것이 신청자가 아니라 흐름 소유자 쪽의 작업이 된다는 것입니다. 승인 요청은 흐름의 연결에 사용된 계정에서 나가며, 승인자 변경에는 흐름 편집 권한이 필요하기 때문입니다. ‘승인자가 휴직했을 때 누가 흐름을 고칠 것인가’를, 다음 장의 공동 소유자 이야기와 세트로 정해 둘 필요가 있습니다.

다만 재할당은 ‘받은 본인이 조작할 수 있다’는 것이 전제이므로, 갑작스러운 휴직 등에는 효과가 없습니다. 상시적인 대비로는 승인자를 개인 한 명으로 고정하지 않고, 여러 명을 세미콜론으로 구분하여 지정해 ‘최초 응답’ 유형으로 하거나, 그룹 앞으로 보내는 설계가 안전합니다.⁹ 그룹 앞으로 보내면 Teams 알림이 가지 않는 제약¹⁰이 있으므로, 알림의 확실성을 중시한다면 복수 명 지정을 선택합니다.

거부 시 반려 루프

종이 결재에서 가장 추적하기 어려웠던 ‘반려→수정→재신청’은, 상태 열을 가진 설계라면 자연스럽게 표현할 수 있습니다. 기본 형태는 이렇습니다.

• 커스텀 응답으로 ‘승인’, ‘반려’를 정의한다¹
• 반려일 경우, 목록의 상태 열을 ‘반려’로 하고, 승인자의 코멘트를 열에 기록하여 신청자에게 통지한다
• 신청자는 목록의 항목을 수정하고 상태를 ‘재신청’으로 바꾼다(또는 Forms에서 다시 제출한다)
• 항목 업데이트를 트리거로 흐름이 다시 실행되어 승인으로 넘어간다

이 형태에서 한 가지 주의가 필요한 것은, 흐름 자체의 다시 쓰기로 흐름이 재시작되어 버리는 것입니다. ‘항목이 작성되거나 변경되면’ 트리거 그대로 두면, 흐름이 상태 열을 ‘승인 대기’나 ‘승인 완료’로 업데이트한 순간, 그 업데이트 자체가 트리거 조건을 충족하여 이중 승인 요청이나 무한 루프가 발생합니다. 클라우드 플로우는 자기 자신을 트리거할 수 있으며, Power Automate도 저장 시 무한 루프 가능성을 경고해 줍니다.¹⁹ 대책은 후단의 조건 분기에서 버리는 것이 아니라, 트리거 조건(trigger conditions)으로 ‘상태 열이 재신청(또는 신규 작성)일 때만 시작한다’고 트리거 쪽에 적는 것입니다. 트리거 조건을 충족하지 않는 업데이트에서는 흐름 실행 자체가 발생하지 않으므로, 실행 횟수도 소비하지 않습니다.²⁰

트리거 조건은 트리거 카드 오른쪽 위 ‘…’에서 설정(Settings) 을 열고, 트리거 조건(Trigger Conditions) 에 @로 시작하는 식을 한 줄씩 적습니다. SharePoint 목록의 선택 항목 열 ApprovalStatus가 ‘재신청’일 때만 시작시키려면 다음과 같습니다.

@equals(triggerOutputs()?['body/ApprovalStatus/Value'], '재신청')

신규 작성(상태 열이 비어 있음)에서도 시작시키고 싶다면, or로 묶습니다.

@or(equals(triggerOutputs()?['body/ApprovalStatus/Value'], '재신청'), empty(triggerOutputs()?['body/ApprovalStatus/Value']))

작성 방식에서 짚어 둘 점이 3가지 있습니다.

• @는 맨 앞에 한 번만 붙입니다. 안에 중첩하는 equals나 empty에는 붙이지 않습니다.
• 선택 항목 열은 /Value까지 지정합니다. 선택 항목 열은 문자열이 아니라 객체로 반환되므로, body/ApprovalStatus로 비교하면 일치하지 않습니다. 한 줄 텍스트 열이라면 /Value는 불필요합니다.
• 열의 내부 이름에 한국어(또는 원어 표시명)를 사용하지 않는다. SharePoint는 열 이름에 아스키 문자가 아닌 문자를 사용하면 내부 이름이 인코딩된 문자열이 되고, 식에 표시 이름을 그대로 적어도 일치하지 않습니다. 흐름에서 참조하는 열은 영숫자 이름으로 만든 뒤 표시 이름을 바꾸면, 이런 식 작성에서 헛수고하지 않아도 됩니다. 내부 이름은 목록 설정의 열 상세 페이지 URL(Field= 뒤)에서 확인할 수 있습니다.

수정 이력은 목록의 버전 이력에 남으므로, ‘어느 버전에 대한 지적인지’가 섞이는 문제도 해소됩니다. 흐름 안에서 Do until 루프를 짜서 1회 실행 안에서 반려를 돌리는 구조도 가능하지만, 30일의 실행 기간 제한에 반려의 왕복 시간도 포함되어 버리므로, 반려할 때마다 실행을 끝내고, 재신청으로 새 실행을 시작하는 설계가 더 안전합니다.

6. 운영과 거버넌스 ── 흐름을 ‘만든 사람의 것’으로 두지 않는다

승인 흐름은 업무의 기간계에 파고들기 때문에, 특정인 의존이 되면 영향이 큽니다. 최소한 다음 2가지는 가동 첫날에 끝냅니다.

• 공동 소유자를 설정한다. 흐름의 소유자는 실행 이력 확인, 흐름 편집・정지, 연결 자격 증명 업데이트까지 할 수 있습니다. 작성자 한 명인 채로 두면, 퇴사・이동한 순간 아무도 고칠 수 없는 흐름이 됩니다. 정보시스템 담당자나 후임 후보를 공동 소유자로 추가해 둡니다. 또한 SharePoint 목록 자체를 공동 소유자로 하여 ‘목록 편집 권한을 가진 사람 = 흐름을 편집할 수 있는 사람’으로 맞추는 기능도 있지만⁶, 이 글처럼 신청자 전원이 쓰는 접수용 목록에서 이것을 하면, 신청자 전원에게 흐름 편집 권한을 넘기게 되어 버립니다. 승인 흐름에서는 사용하지 말고, 공동 소유자는 운영을 담당하는 담당자 개인이나 관리자용 그룹으로 한정하세요.
• 연결 처리를 이해해 둔다. 흐름에서 사용하는 연결(SharePoint나 Outlook에 대한 인증)은 만든 사용자에게 연결되며, 공유된 연결은 그 흐름 안에서만 사용할 수 있습니다. 또한 공동 소유자는 다른 소유자가 만든 연결의 자격 증명을 변경할 수 없습니다.⁶ 승인 결과 통지 메일이 ‘퇴사한 사람의 계정’에서 계속 발송되거나, 계정 비활성화와 동시에 흐름이 멈추는 사고는 여기서 일어납니다. 알림과 기록에 사용할 계정을 어떻게 할지는, 흐름을 만들기 전에 정해 두어야 할 쟁점입니다.

또한 흐름을 다른 부서에서도 사용하게 하는 경우에도, 신청하는 사람들에게 흐름을 공유할 필요는 없습니다. 이 글의 구성에서는 접수 창구(Forms나 SharePoint 목록)에 입력만 할 수 있으면 흐름은 자동으로 시작됩니다. 공유 대상은 편집・운영에 관여하는 사람으로만 좁히고, 공동 소유자는 필요 최소한으로 두는 것이 원칙입니다.²¹

라이선스, 환경 분리, DLP 정책 같은 Power Automate 전체의 거버넌스에 대해서는, 다른 글 「Power Automate로 업무 자동화하기 ── 클라우드 플로우・데스크톱 플로우 구분과 오류 처리 설계」에서 정리했습니다. 승인 흐름도 클라우드 플로우의 일종이므로, 같은 사고방식이 그대로 적용됩니다.

7. Power Automate로 어디까지 할 것인가

Power Automate의 승인은 강력하지만, 결재 규정을 그대로 구현하는 도구는 아닙니다. 경계선의 기준을 들어 보겠습니다.

판단의 감각으로는, ‘흐름의 분기를 종이에 그려서 A4에 안 들어가게 되면, Power Automate의 수비 범위를 벗어나기 시작한다’ 정도로 보고 있습니다. 무리해서 흐름을 키우기보다는, 승인 경로의 결정 로직만 밖(Dataverse 테이블이나 다른 시스템)으로 빼거나, 전용 시스템으로 옮기는 판단 쪽이 결과적으로 더 저렴하게 끝나는 경우가 많습니다.

또한 승인 흐름의 전자화는, 사외와의 종이・팩스 주고받기를 재검토하는 입구가 되는 경우도 흔합니다. 사내 결재가 전자화되었다면, 다음은 팩스 수주나 청구서 주고받기가 후보입니다. 이 부분은 「FAX 수주를 웹으로 옮기려면 ── 이중 운영 기간 설계와 단계적 이행 실무」나 「EDI란 무엇인가? 기업 간 수발주를 어떻게 편하게 만드는가 ── 팩스·메일·수작업 입력에서 데이터 연계로」에서 다루고 있습니다.

8. 정리

종이와 메일 결재의 진짜 문제는 수고가 아니라 ‘상태가 보이지 않는다・기록이 흩어진다・반려를 추적할 수 없다’는 것이었습니다. Power Automate의 승인 흐름은 이 3가지를 ‘신청과 승인 기록을 SharePoint 목록에 모으고, 승인 조작은 Teams/Outlook으로 끝내는’ 형태로 해결합니다. 추가 시스템 투자 없이 시작할 수 있는 경우가 많다는 점도, Microsoft 365를 도입한 회사에는 큰 이점입니다.

한편, 실행 이력 28일・실행 기간 30일이라는 제약을 모르고 만들면, ‘증적이 사라진다’, ‘신청이 조용히 실패한다’ 승인 흐름이 만들어집니다. 결과 다시 쓰기, 타임아웃 분기, 복수 승인자, 공동 소유자. 이 4가지를 처음부터 설계에 넣어 두면, 승인 흐름은 오래도록 안심하고 돌릴 수 있습니다. 그리고 결재 규정의 복잡함을 그대로 구현하고 싶어졌을 때가, 전용 시스템이나 수탁 개발을 검토할 타이밍입니다.

관련 글

• Power Automate로 업무 자동화하기 ── 클라우드 플로우・데스크톱 플로우 구분과 오류 처리 설계
• FAX 수주를 웹으로 옮기려면 ── 이중 운영 기간 설계와 단계적 이행 실무
• EDI란 무엇인가? 기업 간 수발주를 어떻게 편하게 만드는가 ── 팩스·메일·수작업 입력에서 데이터 연계로
• 디지털 인보이스란? ── ‘청구서 PDF를 메일로 보내는 것’과 무엇이 다른가

관련 상담 영역

합동회사 코무라소프트는 Microsoft 365를 활용한 업무 흐름 전자화 상담부터, Power Automate로는 감당할 수 없는 승인·서식 요건의 시스템화까지 다루고 있습니다.

• 기술 상담・설계 리뷰
• Windows 앱 개발
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

Power Automate의 승인 흐름은 Microsoft 365 라이선스만으로 만들 수 있나요?

만들 수 있습니다. 승인(Approvals) 커넥터는 표준 커넥터이므로, 표준 커넥터를 사용할 수 있는 라이선스(Office 365 등)만 있으면 승인 흐름을 만들 수 있습니다. 다만 승인 데이터의 저장소로 Microsoft Dataverse 데이터베이스가 필요하며, 기본 환경에서는 승인 흐름을 처음 만들 때 자동으로 준비됩니다. SharePoint 목록이나 Forms, Teams, Outlook과의 조합도 표준 커넥터 범위 안에서 구성할 수 있습니다.

승인자가 응답하지 않은 채 방치되면 어떻게 되나요?

클라우드 플로우 1회 실행은 최장 30일이며, 승인 대기와 같은 보류 중인 단계도 30일이 지나면 타임아웃됩니다. 그래서 '기한 없는 승인'은 만들 수 없습니다. 실무에서는 승인 작업에 명시적인 타임아웃을 설정하고, '실행 조건 구성'에서 '타임아웃된 경우' 분기를 마련합니다. 타임아웃되면 원래의 승인 대기는 종료되고, 그 이후의 응답은 후속 단계로 흘러가지 않으므로, 이 분기에서는 독촉 알림과 함께 새 승인 요청을 다시 보내는(반복 횟수에 따라 상급자에게 에스컬레이션하는) 설계로 만듭니다. 30일을 넘겨 기다려야 한다면, '승인 만들기(v2)' 작업과 응답을 처리하는 별도 흐름의 2단 구성으로 나눕니다.

승인 기록은 어디에 남나요? 감사에 사용할 수 있나요?

승인 요청과 응답은 Microsoft Dataverse에 레코드로 저장되며, 흐름 자체의 실행 이력은 기본적으로 28일만 표시됩니다. 감사나 나중의 조회를 실행 이력에 의존하는 것은 위험합니다. 실무에서는 승인 결과·승인자·승인 일시·코멘트를 흐름 마지막에 SharePoint 목록의 열에 다시 써서, 신청 데이터와 승인 기록을 한 곳에서 한눈에 볼 수 있도록 설계하는 것을 권장합니다.

승인자가 부재중이거나 퇴사했을 때는 어떻게 해야 하나요?

승인 요청을 받은 본인은 Power Automate의 승인 목록에서 다른 사람에게 재할당(Reassign)할 수 있습니다. 요청을 보낸 쪽은 재할당할 수 없지만, 요청을 취소하고 흐름의 승인자를 변경하여 다시 실행할 수 있습니다. 상시적인 부재에 대비하려면 승인자를 개인 한 명으로 고정하지 않고 여러 명이나 그룹으로 보내는 설계로 해 두면 막히기 어렵습니다. 흐름 자체의 소유자 퇴사에 대비해 공동 소유자를 처음부터 설정해 두는 것도 중요합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.