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

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

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

1. 먼저 결론

• Power Automate의 승인은 「승인을 시작하고 대기」 작업이 기본입니다. 승인 종류는 「모든 사용자의 승인 필요」, 「첫 번째 응답」, 「사용자 지정 응답(모두/한 명)」, 「순차 승인」의 5가지 중에서 고릅니다.¹
• 승인자는 Teams·Outlook·Power Automate 포털·모바일 앱 어디에서든 응답합니다. 승인만을 위해 새 화면 사용법을 익힐 필요는 거의 없습니다.²³
• 신청 창구는 Microsoft Forms / SharePoint 목록 / Teams의 승인 앱 셋이 현실적입니다. 나중에 목록·집계가 필요하면 SharePoint 목록을 축으로 두는 것이 정석입니다.
• 흐름의 실행 기록은 기본값으로 28일만 보이고, 1회 실행은 최장 30일에 타임아웃됩니다. 승인 증적을 실행 기록에 맡기지 말고, 결과를 SharePoint 목록 등에 다시 쓰는 설계를 처음부터 넣습니다.⁴⁵
• 흐름 소유자의 퇴사·인사이동은 승인 흐름에서 가장 큰 운영 위험입니다. 공동 소유자 설정과 연결을 다루는 방식을, 동작을 시작한 그날 안에 끝냅니다.⁶
• 조건 분기가 많은 다단 승인, 대리 결재나 감사 요건이 엄격한 결재 규정을 그대로 구현하려고 하면 Power Automate로는 유지보수가 버겁습니다. 그때는 워크플로 시스템이나 위탁 개발 영역입니다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 21건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

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

종이 결재서나 메일에 첨부한 Excel 승인이 힘든 이유는, 수고 자체보다 「상태가 보이지 않는다」는 점입니다. 상담에서 공통으로 나오는 것은 대체로 다음 셋입니다.

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

이는 「신청 상태와 기록을 한곳에 모은다」로 거의 풀립니다. Microsoft 365를 이미 도입했다면, 그 보관 장소(SharePoint)와 알림 경로(Teams/Outlook)와 자동화(Power Automate)는 이미 손에 있습니다.

3. Power Automate 승인의 기본 구성 요소

「승인을 시작하고 대기」 작업

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

승인 종류는 다섯입니다.¹

사용자 지정 응답을 쓰면 「승인」「거부」 둘이 아니라 「승인」「반려」「보류」 같은 선택지를 정의합니다. 뒤에서 다룰 반려 루프의 부품이 됩니다.

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

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

여기서 처음 나온 Dataverse(데이터버스)는 Power Platform 공통의 데이터 저장 기반입니다. 거칠게 말하면, 자사 Microsoft 365 테넌트 안에 마련되는 클라우드 데이터베이스이며, Power Apps 앱이나 흐름이 다루는 데이터를 두는 곳으로 씁니다. 승인 기능은 이 위에 올라가 있고, 「누구에게·언제 승인을 요청했고, 누가 어떻게 응답했는지」는 Dataverse 테이블에 레코드로 기록됩니다.

일상적인 작성과 운영에서 Dataverse를 신경 쓸 일은 거의 없습니다. 다만 다음 세 장면에서만 등장합니다.

• 새 환경에서 승인을 처음 쓸 때. 기본 환경이면 자동으로 준비되지만, 부서용으로 새로 만든 환경에서는 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. 신청 창구를 어떻게 설계하는가

승인 흐름의 쓰임새는 승인 쪽보다 신청 쪽 입력 창구에서 결정됩니다. 현실적인 선택지는 셋입니다.

판단 기준은 이렇습니다.

• 그때그때 승인만 전자화하고 싶다면, 흐름을 만들지 않아도 Teams의 승인 앱으로 충분합니다. 승인 앱은 채팅에서 그 자리에서 승인 요청을 보내는 기능이며, Power Automate 기반 위에서 동작하지만 흐름 작성은 필요 없습니다.¹¹
• 신청서 대체라면, Forms를 창구로 두고 응답을 흐름으로 받아 승인으로 넘기는 길이 가장 짧습니다. Forms 응답 내용을 승인 요청에 넣는 템플릿도 있습니다.¹³
• 신청 대장으로 관리하고 싶다면 SharePoint 목록을 축으로 둡니다. Forms를 입구로 쓰더라도, 흐름 맨 앞에서 응답을 목록에 옮겨 두면, 상태 열(승인 대기/승인됨/반려)과 보기로 「지금 어디서 멈춰 있는지」가 누구에게나 보입니다. 서두에 든 종이·메일 결재 문제에 대한 답은, 사실상 여기 있습니다.

소규모로 시작한다면 「Forms로 받아 SharePoint 목록에 기록하고, 승인 결과도 목록에 다시 쓰는」 구성이 입력 편의와 대장 관리를 같이 가져가 다루기 쉽습니다.

5. 실무에서 효력이 있는 설계 포인트

승인 기록을 어디에 남기는가 ── 실행 기록에 맡기지 않는다

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

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

실무에서는 승인 작업 직후에 결과·승인자·응답 시각·댓글을 SharePoint 목록 열에 다시 쓰는 단계를 반드시 넣습니다. 「승인을 시작하고 대기」 작업은 응답·승인자·댓글을 출력으로 돌려주므로¹⁵, 그것을 그대로 열에 기록하면 됩니다. 신청과 승인 기록이 같은 목록의 같은 행에 모이고, 보존 기간은 목록 운영에 따라 몇 년이든 가져갈 수 있습니다.

한 가지만 주의합니다. 「모든 사용자의 승인 필요」나 사용자 지정 응답(모두)처럼 여러 승인자가 있는 종류에서는, 응답(Responses)이 인원수만큼의 배열로 돌아옵니다.³ 이를 한 묶음의 열에 차례로 덮어쓰면 마지막 응답만 남습니다. 여러 승인자의 기록은, 응답마다 이력용 목록에 한 행씩 추가하거나, 전원 응답을 하나의 텍스트로 만든 뒤 열에 기록하는 형태로 둡니다.

타임아웃과 미리 알림 ── 「기한 없는 승인」은 만들 수 없다

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

대책은 두 단계입니다.

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

타임아웃과 분기 설정 절차

글로만 보면 잡히기 어려운 부분이므로, 디자이너에서의 조작을 순서대로 적습니다.

1. 「승인을 시작하고 대기」 작업 카드 오른쪽 위 「…」에서 설정(Settings) 을 열고, 타임아웃(Timeout) 칸에 ISO 8601 형식 기간을 넣습니다. 3일이면 P3D, 12시간이면 PT12H입니다. 비워 두면 흐름 실행 기간 상한(30일)까지 기다립니다.
2. 승인 작업 아래에, 타임아웃됐을 때 할 처리(독촉 알림 등) 작업을 하나 둡니다.
3. 그 작업 카드 오른쪽 위 「…」에서 실행 조건 구성(Configure run after) 을 열고, 직전 승인 작업에 대해 「타임아웃됨」만 선택합니다. 기본값은 「성공함」이므로, 이를 끄는 것을 잊지 마십시오.
4. 승인된 경우의 처리(결과 다시 쓰기·신청자 알림)는 승인 작업에서 나온 다른 분기로 나란히 두고, 이쪽은 「성공함」 그대로 둡니다. 실행 조건 구성으로 가지를 나누면, 디자이너에는 두 분기가 나란히 보입니다.

「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

만들 때 포인트는 셋입니다.

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

「타임아웃→독촉→재요청」을 Do until 루프로 감싸는 형태도 만들 수 있지만, Do until에는 루프 자체의 상한(기본값 60회·1시간)이 따로 있습니다. 승인 대기처럼 오래 걸리는 작업을 안에 넣을 때는 「제한 변경」으로 루프 타임아웃을 명시적으로 늘리지 않으면, 1바퀴 다음 2바퀴 이후가 시작되지 않습니다.⁵¹⁸ 이 「제한 변경(Change limits)」은 Do until 작업 카드 안의 링크이며, 열면 개수(Count) 와 타임아웃(Timeout) 둘을 지정합니다. 개수는 반복 횟수(기본값 60), 타임아웃은 루프 전체 제한 시간을 ISO 8601로 적는 칸(기본값 PT1H)입니다. 3일 기다리는 승인을 3바퀴 돌리려면, 개수를 3, 타임아웃을 P10D처럼 「예상 바퀴 시간 합계보다 긴 값」으로 둡니다. 다만 여기를 늘려도 흐름 전체의 30일은 늘어나지 않습니다.

중소기업 결재라면, 먼저 「3일에 독촉, 7일에 상사에게 에스컬레이션」 같은 사내 규칙을 정하고, 이를 재요청 루프 또는 두 흐름 구성으로 구현하는 쪽이 현실적입니다.

부재 시 재할당

승인자가 장기 부재인 경우는 반드시 생깁니다. 승인 요청을 받은 본인은 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']))

적는 법에서 짚을 점은 셋입니다.

• @는 맨 앞 한 번만입니다. 안에 중첩하는 equals나 empty에는 붙이지 않습니다.
• 선택 열은 /Value까지 지정합니다. 선택 열은 문자열이 아니라 개체로 돌아오므로, body/ApprovalStatus로 비교해도 일치하지 않습니다. 한 줄 텍스트 열이면 /Value는 필요 없습니다.
• 열 내부 이름에 한국어를 쓰지 않는다. SharePoint는 열 이름에 한국어를 쓰면 내부 이름이 _x72b6__x614b_ 같은 인코딩 문자열이 되고, 식에 표시 이름을 그대로 적어도 일치하지 않습니다. 흐름에서 참조하는 열은 영숫자 이름으로 만든 뒤 표시 이름을 한국어로 바꾸면, 이런 식에서 시간을 덜 씁니다. 내부 이름은 목록 설정의 열 상세 페이지 URL(Field= 뒤)에서 확인합니다.

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

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

승인 흐름은 핵심 업무에 들어가므로, 한 사람에게 묶이면 영향이 큽니다. 최소한 다음 두 가지는 가동 첫날에 끝냅니다.

• 공동 소유자를 설정한다. 흐름 소유자는 실행 기록 확인, 흐름 편집·중지, 연결 자격 증명 업데이트까지 할 수 있습니다. 만든 사람 한 명인 채로 두면, 퇴사·인사이동한 순간 아무도 고치지 못하는 흐름이 됩니다. 정보시스템 담당자나 후임 후보를 공동 소유자로 넣어둡니다. 참고로 SharePoint 목록 자체를 공동 소유자로 두어 「목록 편집 권한이 있는 사람 = 흐름을 편집할 수 있는 사람」으로 맞추는 기능도 있지만⁶, 이 글처럼 신청자 전원이 쓰는 창구 목록에서 그렇게 하면 신청자 전원에게 흐름 편집 권한을 주게 됩니다. 승인 흐름에서는 쓰지 말고, 공동 소유자는 운영을 맡은 담당자 개인이나 관리자용 그룹으로 한정합니다.
• 연결을 다루는 방식을 이해해 둔다. 흐름에서 쓰는 연결(SharePoint나 Outlook 인증)은 만든 사용자에 묶이고, 공유된 연결은 그 흐름 안에서만 씁니다. 또한 공동 소유자는 다른 소유자가 만든 연결의 자격 증명을 바꾸지 못합니다.⁶ 승인 결과 알림 메일이 「퇴사한 사람 계정」에서 계속 나가거나, 계정 비활성화와 함께 흐름이 멈추는 사고는 여기서 납니다. 알림과 쓰기에 쓸 계정을 어떻게 할지는, 흐름을 만들기 전에 정해 둘 쟁점입니다.

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

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

7. Power Automate로 어디까지 하는가

Power Automate의 승인은 강력하지만, 결재 규정을 그대로 구현하는 도구는 아닙니다. 구분의 기준을 듭니다.

판단 감각으로는, 「흐름 분기를 종이에 그려 A4에 안 들어가면 Power Automate가 다루기 적절한 범위를 넘기 시작한다」 정도로 봅니다. 무리해서 흐름을 키우기보다, 승인 경로 결정 로직만 밖(Dataverse 테이블이나 다른 시스템)으로 빼거나, 전용 시스템으로 옮기는 판단이 결과적으로 더 싸게 끝나는 경우가 많습니다.

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

8. 정리

종이와 메일 결재의 진짜 문제는 수고가 아니라 「상태가 보이지 않는다·기록이 흩어진다·반려를 따라갈 수 없다」였습니다. Power Automate의 승인 흐름은 이 셋을 「신청과 승인 기록을 SharePoint 목록에 모으고, 승인 조작은 Teams/Outlook에서 끝낸다」는 형태로 풉니다. 추가 시스템 투자 없이 시작하는 경우가 많다는 점도, Microsoft 365를 이미 도입한 회사에는 큰 이점입니다.

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

관련 글

• Power Automate로 업무를 자동화하기 ── 클라우드 흐름·데스크톱 흐름 구분과 오류 처리 설계
• 팩스 수주를 웹으로 옮기려면 ── 이중 운영 기간 설계와 단계적 이행의 실무
• 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) 작업과 응답을 처리하는 별도 흐름으로 나눈 구성으로 둡니다.

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

승인 요청과 응답은 Microsoft Dataverse에 레코드로 저장되고, 흐름 자체의 실행 기록은 기본값으로 28일만 표시됩니다. 감사나 이후 조회를 실행 기록에 맡기는 것은 위험합니다. 실무에서는 승인 결과·승인자·승인 시각·댓글을 흐름 마지막에 SharePoint 목록 열에 다시 써서, 신청 데이터와 승인 기록을 한곳에서 볼 수 있게 두는 설계를 권합니다.

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

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

저자 프로필

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

Go Komura

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

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