제휴 및 광고 고지: 이 글은 자동화 도구를 비교하고 선택하는 독자를 위한 정보성 글입니다. 일부 링크에는 제휴 또는 광고 성격이 포함될 수 있으며, 최종 도입 전 공식 요금제와 약관을 확인해야 합니다.
회사 결재 자동화는 사람이 할 판단을 없애는 작업이 아닙니다. 요청 내용을 모으고, 정해진 승인자에게 전달하고, 승인·반려 결과에 따라 기록을 갱신하는 흐름입니다. 지급·계약 체결처럼 별도 권한이 필요한 작업은 승인 알림과 분리해 설계하세요.
승인 규칙부터 한 문장으로 정하기
요청 번호, 요청자, 사유, 금액과 통화, 증빙 링크, 승인자, 처리 상태를 준비합니다. 승인자가 증빙을 열 수 있는지도 확인합니다. ‘팀장 한 명의 결정’인지 ‘여러 명 전원 동의’인지 ‘정해진 순서의 승인’인지 먼저 구분합니다.
First to respond 유형은 지정된 승인자 중 한 명의 승인 또는 반려로 요청을 끝냅니다. 전원이 확인해야 하는 결재에 그대로 사용하면 의도가 달라집니다. 공식 문서의 승인 유형을 업무 규정과 맞춰 선택해야 합니다. 승인 시작하기
요청 목록에서 승인 응답까지 구성하기
다음은 SharePoint 목록에 새 결재 요청을 등록하는 설계 예시입니다.
- 테스트용 요청 목록을 만들고 필요한 필드를 준비합니다. 새 항목이 생길 때 시작하는 자동화된 클라우드 흐름을 구성합니다.
- Approvals의 Start and wait for an approval 작업을 추가합니다. 폐기된 이름의 작업과 혼동하지 않도록 현재 작업을 선택합니다.
- 승인 유형, 제목, Assigned to, 상세 내용을 채웁니다. 요청 번호와 검토할 원본 링크를 포함합니다.
- 승인 응답의 Outcome을 조건으로 검사하고 승인일 때와 반려일 때 각각 요청 상태를 기록하도록 구성합니다.
- 요청자 안내는 해당 분기에 연결합니다. 알림을 전송했다는 사실과 후속 처리 완료를 별도 상태로 기록합니다.
Microsoft 공식 예시는 승인 작업을 추가하고 승인·반려에 따라 요청을 갱신하는 흐름을 안내합니다. 테스트를 실행하면 승인 요청과 이메일이 실제로 만들어지므로 테스트 승인자와 전용 목록을 사용해야 합니다. 승인 흐름 만들기와 시험
Create와 Start and wait의 차이
Create an approval은 승인 요청을 만들지만 응답을 기다리지 않습니다. 이후 작업이 승인 뒤에만 실행돼야 한다면 이 차이를 놓치면 안 됩니다. Start and wait for an approval은 승인 완료를 기다리는 작업이며, 분리 구성이 필요한 경우 Wait for an approval과 승인 ID 연결을 검토합니다. Approvals 커넥터 참조
가상의 소프트웨어 구매 요청에서 승인 후에는 ‘구매 검토 승인’을 기록할 수 있습니다. 실제 결제는 별도의 구매 권한자가 수행하고 결과를 기록합니다. 견적 변경으로 금액이 달라졌다면 기존 승인 내용을 수정해 덮어쓰기보다 재검토 기준을 정합니다.
응답이 없거나 재실행할 때
미응답·취소·오류를 반려나 승인으로 간주하지 않습니다. 담당자는 대기 요청 목록을 확인하고 부재 중 승인자의 대체 절차를 적용합니다. 실행 오류 후에는 이미 승인 요청이 생성됐는지 먼저 확인해 같은 결재를 중복 발송하지 않습니다.
클라우드 흐름의 실행 시간에는 대기 중인 승인도 포함되며 공식 한도 문서는 30일을 안내합니다. 승인 관련 알려진 문제에는 별도 대기 제한도 있으므로 장기 결재를 무기한 대기 흐름 하나로 설계하지 마세요. 장기 승인은 Microsoft가 안내하는 저장·응답 처리 분리 방식을 검토해야 합니다. 실행 한도 · 승인 알려진 문제
Approvals는 표준 커넥터이지만 생성·응답 권한, 환경의 Dataverse 준비, 함께 쓰는 다른 커넥터의 라이선스도 확인해야 합니다. 모든 Microsoft 계정에서 비용 없이 같은 구성이 된다는 뜻은 아닙니다. 전제 조건과 라이선스
2026년 9월 27일 공식 자료를 확인했으며, 실제 회사 결재 요청·이메일·지급 작업은 실행하지 않았습니다.