Power Automate 승인했는데 카드가 남을 때, 실패한 흐름 확인 순서
승인자는 처리했다고 하는데 Teams 카드에는 아직 버튼이 보이나요? 바로 승인 요청을 다시 보내기 전에, Power Automate의 실행 기록과 승인 항목 상태부터 확인하세요. 화면에 남은 카드와 실제 흐름의 상태가 서로 다를 수 있어요.
특히 오래 기다린 승인에서는 ‘승인 요청이 남아 있음’과 ‘그 응답을 기다리는 흐름이 살아 있음’을 구분해야 해요. 이 둘을 같은 상태로 보면 이미 끝난 요청을 다시 보내거나, 아무도 받지 않는 응답을 기다리는 일이 생길 수 있어요.
직접 제작한 진단용 개념도. 실제 서비스 화면이나 특정 장애 기록이 아닙니다.
1. 이메일에서 승인했다면 카드부터 의심하지 마세요
Microsoft의 알려진 문제 문서에 따르면, 이메일이나 승인 센터에서 응답한 경우 Teams의 승인 Adaptive Card가 자동 갱신되지 않을 수 있어요. 이 때문에 카드와 실제 흐름의 상태가 달라 보일 수 있어요. 승인 카드 상태 불일치 안내
예를 들어 가상의 ‘장비 대여 승인’ 요청을 이메일에서 승인했다고 해볼게요. Teams에 버튼이 남았다는 이유만으로 미승인이라고 판단하지 말고, 해당 실행의 승인 단계 결과와 이후 단계를 확인해요. 승인 결과는 들어왔지만 후속 목록 수정에서 실패했을 수도 있어요.
팀 내 문의를 받을 때는 요청 제목만 받기보다 요청 시간, 승인한 경로, 관련 실행을 함께 확인할 수 있는 정보를 모으세요. 같은 제목의 요청이 여러 번 만들어졌다면 제목만으로는 어느 건인지 구분하기 어려워요.
2. 28일과 30일은 같은 숫자의 다른 표현이 아닙니다
현재 공식 문서에는 두 제한이 별도로 설명되어 있어요.
- 승인 알려진 문제: 응답 대기가 28일을 넘으면 해당 승인 흐름이 실패할 수 있고, 승인 항목은 승인 센터에 남을 수 있음
- 클라우드 흐름 실행 제한: 한 번의 실행은 시작 시점부터 최대 30일이며, 대기 중인 단계도 이 시간에 포함됨
따라서 ‘흐름은 30일까지니까 승인도 그때까지 안전하게 기다린다’고 설계하면 곤란해요. 28일 안내는 승인 대기와 남겨진 승인 항목에 관한 설명이에요. 30일은 전체 흐름 실행의 상한이에요. 실제 실패 원인은 실행 기록의 시간과 오류로 확인해야 해요. 승인 대기 알려진 문제, 흐름 기간 제한
공식 문서의 서로 다른 제한을 구분한 설명도. 실제 실행의 만료 시점을 예측하는 타임라인은 아닙니다.
3. 실행 기록은 마지막 오류보다 첫 실패 지점부터 봅니다
아래 순서로 메모를 남기면 원인을 좁히기 좋아요.
- 환경과 흐름 이름이 맞는지 확인해요.
- 문제가 생긴 실행의 시작 시각과 현재 상태를 기록해요.
- 승인 생성, 응답 대기, 후속 처리 중 어디에서 멈췄는지 봐요.
- 실패한 액션의 오류 코드와 표시 메시지를 확인해요.
- 연결 계정, 권한, 라이선스 또는 시간 초과 중 어떤 문제인지 구분해요.
OperationTimedOut처럼 긴 대기와 관련된 오류라면 명시적인 제한 시간과 시간 초과 분기를 점검할 수 있어요. Microsoft는 30일을 넘는 업무를 여러 실행으로 나누고 상태를 이어받는 설계를 안내해요. 단순히 반복문 안에서 계속 기다린다고 단일 실행 제한이 없어지지는 않아요. 클라우드 흐름 오류 코드 안내
오류 화면을 AI나 외부 지원에 전달할 때는 입력·출력에 포함된 고객 정보, 내부 주소, 토큰 등을 먼저 가리세요. 오류 코드와 실패 액션 이름만으로 방향을 잡을 수 있는지부터 확인하는 편이 안전해요.
4. 재실행 전에는 이미 처리된 결과를 확인하세요
가상 예시를 이어가 볼게요. 승인 자체는 성공했고 ‘대여 목록에 행 추가’도 완료됐지만, 마지막 알림만 실패했다면 전체 흐름 재실행으로 같은 행이 또 생길 수 있어요.
그래서 재실행 판단 전에 ‘무엇이 이미 바뀌었는지’를 먼저 적어야 해요. 승인 결과, 생성된 기록, 발송된 메시지를 대조하고 필요한 부분만 복구할 수 있는지 검토하세요. 업무 식별번호를 기록해 두면 같은 건이 중복 처리되는지 찾는 데 도움이 돼요.
승인 센터에 오래 남은 항목을 정리할 때도 기존 실행과 연결 관계를 먼저 확인하세요. Microsoft는 대기 흐름이 사라진 승인 항목을 요청자나 환경 관리자가 수동 정리해야 하는 경우를 안내해요. 감사나 내부 보존 규칙이 있다면 그것부터 확인하는 것이 좋아요. 남겨진 승인 항목 안내
다음번에는 만료 후 동작까지 정해두세요
예를 들어 내부 규칙상 이틀 안에 답을 받아야 하는 업무라면, 시스템 최대치까지 기다리는 대신 업무 기한을 명시하고 미응답 처리 경로를 설계해 보세요. 이틀이라는 값은 이 글의 예시이며 모든 조직에 맞는 기준은 아니에요.
기한이 지났을 때 누구에게 알릴지, 원래 요청은 어떻게 처리할지, 새 요청을 만들면 이전 요청과 어떻게 구분할지까지 정해야 해요. 시간 초과 경로에서 다시 승인 대기로 들어가는 구조라면 종료 조건도 확인하세요.
가상 장애 기록 한 건을 따라가 보겠습니다
‘장비 대여 요청 R-014’라는 가상 업무를 생각해 볼게요. 요청을 만들고 승인을 받은 뒤 대여 목록에 항목을 추가하고 담당자에게 알림을 보내는 흐름이에요. 아래 내용은 실제 서비스 실행 결과가 아니라 점검 순서를 설명하기 위한 예시예요.
- 승인 요청 생성: 완료
- 승인 응답 수신: 승인으로 완료
- 대여 목록 항목 추가: 완료
- 담당자 알림: 실패
이 기록에서 복구해야 할 대상은 어디일까요? 승인부터 새로 받기 전에 마지막 알림이 왜 실패했는지 확인해야 해요. 대여 목록에 이미 항목이 추가됐다면 기존 항목을 기준으로 알림만 복구할 수 있는지 검토할 수 있어요. 실제 가능한 복구 방법은 흐름의 액션과 권한 구성에 따라 달라져요.
반대로 승인 응답은 왔지만 목록 추가에서 실패했다면, 목록에 동일한 요청이 이미 있는지도 확인한 뒤 해당 단계를 복구할지 판단해야 해요. ‘실패’라는 전체 상태만 보고 앞선 모든 액션이 취소됐다고 가정하지 않는 것이 중요해요.
복구 기록에는 가상 요청 번호 R-014, 실패 단계, 이미 생긴 결과, 복구 방법을 한 줄씩 남겨보세요. 다음 담당자가 같은 요청을 보고 다시 처리하지 않도록 판단 근거가 이어지는 것이 목적이에요.
실제 장애 로그가 아닌 설명용 가상 실행 기록입니다.
문의가 들어오면 이 다섯 가지를 먼저 받으세요
첫째, 요청이 만들어진 시간이에요. 같은 제목의 요청이 반복될 때 어느 실행인지 구분하는 데 필요해요. 화면에 표시된 시간대가 무엇인지도 함께 적으면 팀 간 시차로 인한 혼선을 줄일 수 있어요.
둘째, 승인자가 응답한 경로와 시간이에요. 이메일인지 Teams인지 승인 센터인지 확인하면 카드 표시 불일치 가능성을 따져보기 쉬워요. 요청자의 추측보다 승인자가 실제로 한 동작을 기준으로 기록하세요.
셋째, 요청 식별 정보와 실행 식별 정보예요. 제목만으로 추적이 어려운 흐름에서는 같은 업무를 연결할 수 있는 번호나 링크가 도움이 돼요. 내부 링크는 지원에 필요한 사람에게만 전달하고 공개 게시판에 그대로 올리지 않는 편이 좋아요.
넷째, 첫 실패 액션의 오류 코드예요. 뒤에 붙은 ‘실행되지 않음’ 항목을 원인으로 착각하지 않도록 앞선 실패 지점을 확인해요. 입력·출력 원문을 공유해야 한다면 필요한 부분만 발췌하고 민감한 값을 제거하세요.
다섯째, 이미 발생한 외부 결과예요. 목록에 항목이 생겼는지, 메일이 도착했는지, 다른 시스템에 반영됐는지 확인해요. 이 정보가 있어야 전체 재실행과 부분 복구의 위험을 비교할 수 있어요.
시간 초과 경로도 정상 업무처럼 설계해 봅니다
가상 규칙을 ‘요청 후 이틀 안에 응답이 없으면 담당자가 상태를 검토한다’로 정해볼게요. 이 경우 시간 초과 뒤 곧바로 같은 승인 요청을 무한히 보내는 대신, 요청 번호와 미응답 상태를 남기고 검토 대상에 올리는 흐름을 생각할 수 있어요.
상태 이름도 구체적으로 정해요. ‘실패’ 하나로만 표시하면 기술 오류인지, 승인자가 아직 응답하지 않은 것인지, 요청자가 취소한 것인지 알기 어려워요. 업무 목록에서는 ‘응답 기한 경과’, ‘연결 오류 확인 필요’, ‘요청 취소’처럼 담당자가 다음 행동을 판단할 수 있게 구분하는 방식을 고려하세요.
새 승인 요청을 만들게 된다면 기존 요청과 새 요청을 어떻게 연결할지도 정해야 해요. 같은 제목만 반복하지 않고 재요청임을 표시하거나 업무 번호를 연결해 두면 승인자가 어느 요청을 처리해야 하는지 이해하기 쉬워요. 이런 문구와 재요청 정책은 조직의 업무 규칙에 맞춰 정하세요.
장기 승인을 여러 흐름 실행으로 나누는 경우에는 상태를 저장하는 위치와 저장 권한, 다음 실행이 같은 업무를 이어받는 기준을 함께 검토해야 해요. 오류가 났을 때 마지막으로 확정된 상태가 무엇인지 알아야 다시 시작하는 위치를 결정할 수 있어요. 단순히 흐름 개수를 늘리는 것만으로 안정성이 확보되지는 않아요.
운영에 반영하기 전 테스트할 작은 목록
정상 승인만 시험하지 말고 반려, 미응답, 취소, 연결 오류도 가능한 범위에서 테스트해 보세요. 각 경우에 승인 요청, 업무 목록, 담당자 알림이 어떤 최종 상태로 남아야 하는지 기대값을 적어두는 것이 좋아요.
예를 들어 반려됐을 때 대여 목록에 승인 완료 항목이 추가되지 않아야 한다는 기준을 둘 수 있어요. 또 알림만 실패했을 때 이미 완료된 대여 기록을 중복 생성하지 않는지 확인할 수 있어요. 이 기준들은 가상 업무의 예시이므로 실제 흐름의 규칙과 다르면 수정해야 해요.
테스트로 만든 승인 요청과 목록 항목에는 식별 가능한 이름을 붙이고, 종료 후 정리할 대상도 기록하세요. 운영 데이터와 테스트 데이터를 섞지 않는 작은 습관이 나중에 남겨진 승인 항목을 찾을 때 도움이 돼요.
자주 묻는 질문
카드를 다시 누르면 해결되나요? 이미 처리된 요청일 수 있으니 먼저 승인 결과와 실행 기록을 확인하세요. 카드 모양만으로 상태를 판단하지 않는 것이 출발점이에요.
30일 이상 걸리는 승인 업무는 못 만드나요?
한 번의 흐름 실행을 무기한 유지하는 방식에는 제한이 있어요. 업무 상태를 별도 저장하고 여러 실행으로 나누는 설계를 검토할 수 있지만, 저장소·커넥터의 권한과 라이선스 조건도 함께 확인해야 해요. 기간 제한 및 오류 설계 안내
Create와 Wait 액션을 나눠도 되나요? 공식 알려진 문제에는 승인 생성과 대기 사이가 벌어지고 응답이 먼저 도착하면 대기에 걸릴 수 있다고 나와요. 분리했다면 두 액션 사이의 단계와 타이밍부터 확인하세요. 분리된 생성·대기 액션의 주의점
카드가 남았다는 현상과 실제 업무가 멈췄다는 사실을 먼저 분리해 확인하면, 불필요한 재요청을 줄이고 정확한 복구 지점을 찾기 쉬워져요.
