솔루션 핸드북
설정, Jodoo 필드, 검증 레코드, 도입 참고 사항을 포함한 Make 구매 요청 승인 라우팅 루프 계획 가이드입니다.
핸드북 열기MAKE + JODOO
Make와 Jodoo가 구매 요청 승인 라우팅을 처리하는 방식을 확인해 보세요. 원본 요청을 검토하고, 구조화된 의사결정 필드를 반환하며, 결과를 Jodoo에 기록하고, 담당자, 상태, 다음 액션을 계속 확인할 수 있습니다.
일관된 기준으로 구매 요청 데이터를 검토
승인 상태, 소싱 상태, 구매 담당자, 승인 경로, 누락 정보, 예상 총액, 우선순위, 권장 다음 액션을 Jodoo에 기록
담당자 대기열과 후속 조치 상태를 계속 확인
워크플로를 프로덕션 소스에 맞게 조정하기 전에 Make 검증 결과 활용
공개 검증은 Make Run once 모드를 사용하므로 캡처된 스크린샷에서 시나리오 기록의 웹훅 번들, 모듈 버블, 작업 수, HTTP 응답을 확인할 수 있습니다.
동영상 안내
동영상에서는 현장 서비스 팀이 예산 코드, 출시 일정, 예상 지출, 누락된 기기 관리 세부정보와 함께 러기드 태블릿 12대를 요청하면 Make가 이를 처리하고, Jodoo가 운영 레코드를 저장하는 과정을 보여줍니다.
현장 서비스 팀이 예산 코드, 출시 일정, 예상 지출, 누락된 기기 관리 세부정보와 함께 러기드 태블릿 12대를 요청합니다.
워크플로는 느슨한 문단을 반환하는 대신 승인 상태, 소싱 상태, 구매 담당자, 승인 경로, 누락 정보, 예상 총액, 우선순위, 권장 다음 액션을 명확하게 유지합니다.
테스트된 실행은 검토 결과를 Jodoo로 전송하고 브리지에서 Jodoo 데이터 ID를 수신합니다.
공개 검증은 Make Run once 모드를 사용하므로 캡처된 스크린샷에서 시나리오 기록의 웹훅 번들, 모듈 버블, 작업 수, HTTP 응답을 확인할 수 있습니다.
Jodoo 앱은 검토와 후속 조치를 위해 요청자 이름, 부서, 요청일, 우선순위, 품목 카테고리, 품목 설명, 수량을 저장합니다.
데모 요약
이 구현은 시각적인 시나리오 캔버스, Run once 테스트, 모듈 기록을 원하는 운영팀에 적합합니다. 이 페이지에서는 시각적 시나리오 설정, 실제 실행, Jodoo 기록 반영을 모두 확인할 수 있습니다. HTTP 모듈 증거는 시각적으로 제공됩니다. 코드 편집기를 열지 않아도 메서드, 엔드포인트, 본문 유형, 파싱된 응답, 완료 상태를 모두 검사할 수 있습니다.
Make Custom webhook이 샘플 페이로드를 수신하고 HTTP 모듈이 구조화된 필드를 Jodoo로 전송합니다.
워크플로는 보호 케이스와 기기 등록 지원을 포함한 현장 서비스 팀용 러기드 태블릿 12대에 대해 승인 상태, 소싱 상태, 구매 담당자, 승인 경로, 누락 정보, 예상 총액, 우선순위, 권장 다음 액션을 반환합니다.
Make 실행 기록에는 HTTP 모듈 완료, 작업 세부정보, Jodoo 데이터 ID 응답이 표시됩니다.
Custom webhook으로 시작하고, 샘플 요청을 붙여 넣은 다음, 의사결정 필드를 HTTP 모듈 본문에 매핑하기 전에 Make가 번들을 추론하도록 합니다.
구매 요청 승인 라우팅에서는 HTTP 모듈이 Jodoo에 기록하기 전에 Make 번들에서 요청자, 부서, 품목, 수량, 예상 총액, 예산 코드, 필요 기한, 누락 정보를 확인할 수 있어야 합니다.
Jodoo는 구매 요청 레코드를 저장하고 다음 액션을 계속 표시합니다.
권장 다음 액션은 공급업체 견적을 요청하고, 예산 담당자 승인을 확인한 뒤, 소싱 전에 요청을 재무팀으로 라우팅하는 것입니다.
핵심 키트에는 핸드북, Jodoo 필드 설계도, Make 워크플로 레시피가 포함됩니다.
플랫폼 설정 참고사항
Jodoo 레코드 모델은 일관되게 유지할 수 있지만, 각 에이전트 플랫폼은 구축 방식, 테스트 화면, 운영 배포 방식이 다릅니다.
검증에는 Run once를 사용하므로 수신 번들과 HTTP 응답을 확인할 수 있습니다.
HTTP 모듈은 메서드, URL, 본문 유형, 응답 파싱을 검사할 수 있게 유지합니다.
시나리오 기록은 작업, 기간, 기록 반영 응답에 대한 시각적 레코드를 제공합니다.
프로덕션 계획에는 웹훅 담당자, 라우터, 오류 처리기, 작업 사용량이 포함되어야 합니다.
공개 검증은 Make Run once 모드를 사용하므로 캡처된 스크린샷에서 시나리오 기록의 웹훅 번들, 모듈 버블, 작업 수, HTTP 응답을 확인할 수 있습니다.
HTTP 모듈 증거는 시각적으로 제공됩니다. 코드 편집기를 열지 않아도 메서드, 엔드포인트, 본문 유형, 파싱된 응답, 완료 상태를 모두 검사할 수 있습니다.
Custom webhook으로 시작하고, 샘플 요청을 붙여 넣은 다음, 의사결정 필드를 HTTP 모듈 본문에 매핑하기 전에 Make가 번들을 추론하도록 합니다.
고액 계약, 긴급 청구서, 정보 누락 사례에 서로 다른 Jodoo 대기열이 필요한 경우 기본 검증 후 라우터를 사용하세요.
Run once 검증을 활성 워크플로로 전환하기 전에 작업 사용량, 웹훅 담당자, 시나리오 일정을 검토하세요.
기록 반영 실패를 재시도하거나 수동 검토 경로로 이동할 수 있도록 HTTP 모듈 주변에 오류 처리기를 추가하세요.
구매 요청 승인 라우팅에서는 HTTP 모듈이 Jodoo에 기록하기 전에 Make 번들에서 요청자, 부서, 품목, 수량, 예상 총액, 예산 코드, 필요 기한, 누락 정보를 확인할 수 있어야 합니다.
첫 번째 기록 반영 검증이 안정화된 후 라우터는 소액 요청, 견적 필요 구매, 재무 승인, 긴급 소싱 업무를 분기할 수 있습니다.
워크플로 키트
핸드북을 검토하고, 워크플로 레시피를 복사한 뒤, Make 워크플로를 조정할 때 Jodoo 필드 모델을 활용하세요.
재사용 가능한 워크플로
보호 케이스와 기기 등록 지원을 포함한 현장 서비스 팀용 러기드 태블릿 12대로 구매 요청 테스트를 시작합니다. Custom webhook으로 시작하고, 샘플 요청을 붙여 넣은 다음, 의사결정 필드를 HTTP 모듈 본문에 매핑하기 전에 Make가 번들을 추론하도록 합니다.
Make Custom webhook이 샘플 페이로드를 수신하고 HTTP 모듈이 구조화된 필드를 Jodoo로 전송합니다.
구조화된 JSON을 Jodoo 기록 반영 브리지로 전송합니다. HTTP 모듈 증거는 시각적으로 제공됩니다. 코드 편집기를 열지 않아도 메서드, 엔드포인트, 본문 유형, 파싱된 응답, 완료 상태를 모두 검사할 수 있습니다.
성공적인 플랫폼 실행과 Jodoo 데이터 ID를 보여줍니다. 공개 검증은 Make Run once 모드를 사용하므로 캡처된 스크린샷에서 시나리오 기록의 웹훅 번들, 모듈 버블, 작업 수, HTTP 응답을 확인할 수 있습니다.
담당자 검토, 상태 추적, 후속 조치를 위한 필드를 저장합니다. Run once 검증을 활성 워크플로로 전환하기 전에 작업 사용량, 웹훅 담당자, 시나리오 일정을 검토하세요.
워크플로 루프
Custom webhook이 먼저 합성 데이터로 구매 요청 승인 라우팅을 수신하거나 시작합니다.
Make가 집중 검토 지침을 적용하고 승인 상태, 소싱 상태, 구매 담당자, 승인 경로, 누락 정보, 예상 총액, 우선순위, 권장 다음 액션을 반환합니다.
HTTP 모듈이 구조화된 출력을 Jodoo 기록 반영 브리지로 전송하고 데이터 ID를 수신합니다.
구매 요청 승인 라우팅에서는 HTTP 모듈이 Jodoo에 기록하기 전에 Make 번들에서 요청자, 부서, 품목, 수량, 예상 총액, 예산 코드, 필요 기한, 누락 정보를 확인할 수 있어야 합니다.
첫 번째 기록 반영 검증이 안정화된 후 라우터는 소액 요청, 견적 필요 구매, 재무 승인, 긴급 소싱 업무를 분기할 수 있습니다.
시나리오 기록은 각 모듈, 작업 수, 응답 본문, 수락된 Jodoo 데이터 ID를 보여주므로 구매팀에 강력한 검증 근거가 됩니다.
검증 후 Make는 구매 알림, 재무 승인 분기, 공급업체 견적 조회, 기록 반영 실패를 위한 오류 처리기를 추가할 수 있습니다.
Custom webhook으로 시작하고, 샘플 요청을 붙여 넣은 다음, 의사결정 필드를 HTTP 모듈 본문에 매핑하기 전에 Make가 번들을 추론하도록 합니다.
고액 계약, 긴급 청구서, 정보 누락 사례에 서로 다른 Jodoo 대기열이 필요한 경우 기본 검증 후 라우터를 사용하세요.
Jodoo는 구매 요청 양식 레코드를 생성하고 요청자 이름, 부서, 요청일, 우선순위, 품목 카테고리, 품목 설명, 수량, 예상 단가를 저장합니다.
팀은 대기열을 검토하고 담당자를 배정한 뒤 다음 액션을 완료합니다. 공급업체 견적을 요청하고, 예산 담당자 승인을 확인한 후, 소싱 전에 요청을 재무팀으로 라우팅합니다.
Run once 검증을 활성 워크플로로 전환하기 전에 작업 사용량, 웹훅 담당자, 시나리오 일정을 검토하세요.
기록 반영 실패를 재시도하거나 수동 검토 경로로 이동할 수 있도록 HTTP 모듈 주변에 오류 처리기를 추가하세요.
필드 매핑
| 에이전트 또는 소스 데이터 | Jodoo 레코드 필드 |
|---|---|
| 원본 요청 세부정보 | 요청자 이름, 부서, 요청일, 우선순위 |
| 검토 의사결정 필드 | 수량, 예상 단가, 예상 총액, 필요 기한, 예산 코드 |
| 워크플로 응답 | 소스 플랫폼, 원본 워크플로 출력 |
에이전트 레시피
구매 요청 승인 라우팅 요청 1건을 검토하고 Jodoo가 저장, 라우팅, 보고할 수 있는 구조화된 필드를 반환합니다. Custom webhook으로 시작하고, 샘플 요청을 붙여 넣은 다음, 의사결정 필드를 HTTP 모듈 본문에 매핑하기 전에 Make가 번들을 추론하도록 합니다.
보호 케이스와 기기 등록 지원을 포함한 현장 서비스 팀용 러기드 태블릿 12대 샘플 컨텍스트를 사용해 승인 상태, 소싱 상태, 구매 담당자, 승인 경로, 누락 정보, 예상 총액, 우선순위, 권장 다음 액션을 결정하고, 권장 다음 액션은 구체적으로 유지합니다. 구매 요청 승인 라우팅에서는 HTTP 모듈이 Jodoo에 기록하기 전에 Make 번들에서 요청자, 부서, 품목, 수량, 예상 총액, 예산 코드, 필요 기한, 누락 정보를 확인할 수 있어야 합니다.
HTTP 모듈을 통해 예측 가능한 JSON 객체를 전송합니다. Jodoo는 매 실행마다 동일한 필드 이름을 수신해야 합니다. 운영팀이 캔버스, 필터, 라우터, 모듈 수준 실행 기록으로 업무 인계를 설명하고자 할 때 Make가 유용합니다.
감사 컨텍스트를 위해 승인 상태, 소싱 상태, 구매 담당자, 승인 경로, 누락 정보, 예상 총액, 우선순위, 권장 다음 액션, source_platform, agent_confidence, 원본 워크플로 출력을 반환합니다.
Run once 검증을 활성 워크플로로 전환하기 전에 작업 사용량, 웹훅 담당자, 시나리오 일정을 검토하세요. 기록 반영 실패를 재시도하거나 수동 검토 경로로 이동할 수 있도록 HTTP 모듈 주변에 오류 처리기를 추가하세요. 웹훅 URL 담당자와 프로덕션 요청 데이터를 전달하는 모듈을 편집할 수 있는 사람을 문서화하세요.
구매 요청 승인 라우팅에서는 HTTP 모듈이 Jodoo에 기록하기 전에 Make 번들에서 요청자, 부서, 품목, 수량, 예상 총액, 예산 코드, 필요 기한, 누락 정보를 확인할 수 있어야 합니다. 첫 번째 기록 반영 검증이 안정화된 후 라우터는 소액 요청, 견적 필요 구매, 재무 승인, 긴급 소싱 업무를 분기할 수 있습니다. 시나리오 기록은 각 모듈, 작업 수, 응답 본문, 수락된 Jodoo 데이터 ID를 보여주므로 구매팀에 강력한 검증 근거가 됩니다. 검증 후 Make는 구매 알림, 재무 승인 분기, 공급업체 견적 조회, 기록 반영 실패를 위한 오류 처리기를 추가할 수 있습니다.
{
"requester_name": "Avery Brooks",
"department": "운영팀",
"item_category": "IT 장비",
"item_description": "현장 서비스 팀을 위한 러기드 태블릿 12대",
"quantity": 12,
"estimated_total": 5820,
"needed_by_date": "2026-06-21",
"budget_code": "OPS-FIELD-2026",
"approval_status": "검토 대기",
"sourcing_status": "견적 필요",
"approval_route": "부서 관리자 후 재무팀",
"procurement_owner": "구매 운영팀",
"missing_information": "장치 관리 라이선스 수량과 배송 주소 확인",
"recommended_next_action": "소싱 전에 공급업체 견적을 요청하고 재무팀에 전달"
}Jodoo 스타터 앱
팀의 구매 요청 승인 라우팅 워크플로를 조정할 때 필드 모델, 보기, 자동화를 활용하세요.
배포 체크리스트
워크플로
Make는 시각적 시나리오를 처리하고, Jodoo는 팀이 필터링, 배정, 검토할 수 있는 레코드를 유지합니다.
Custom webhook이 먼저 합성 데이터로 구매 요청 승인 라우팅을 수신하거나 시작합니다.
Make가 집중 검토 지침을 적용하고 승인 상태, 소싱 상태, 구매 담당자, 승인 경로, 누락 정보, 예상 총액, 우선순위, 권장 다음 액션을 반환합니다.
HTTP 모듈이 구조화된 출력을 Jodoo 기록 반영 브리지로 전송하고 데이터 ID를 수신합니다.
구매 요청 승인 라우팅에서는 HTTP 모듈이 Jodoo에 기록하기 전에 Make 번들에서 요청자, 부서, 품목, 수량, 예상 총액, 예산 코드, 필요 기한, 누락 정보를 확인할 수 있어야 합니다.
첫 번째 기록 반영 검증이 안정화된 후 라우터는 소액 요청, 견적 필요 구매, 재무 승인, 긴급 소싱 업무를 분기할 수 있습니다.
시나리오 기록은 각 모듈, 작업 수, 응답 본문, 수락된 Jodoo 데이터 ID를 보여주므로 구매팀에 강력한 검증 근거가 됩니다.
검증 후 Make는 구매 알림, 재무 승인 분기, 공급업체 견적 조회, 기록 반영 실패를 위한 오류 처리기를 추가할 수 있습니다.
Custom webhook으로 시작하고, 샘플 요청을 붙여 넣은 다음, 의사결정 필드를 HTTP 모듈 본문에 매핑하기 전에 Make가 번들을 추론하도록 합니다.
고액 계약, 긴급 청구서, 정보 누락 사례에 서로 다른 Jodoo 대기열이 필요한 경우 기본 검증 후 라우터를 사용하세요.
Jodoo는 구매 요청 양식 레코드를 생성하고 요청자 이름, 부서, 요청일, 우선순위, 품목 카테고리, 품목 설명, 수량, 예상 단가를 저장합니다.
팀은 대기열을 검토하고 담당자를 배정한 뒤 다음 액션을 완료합니다. 공급업체 견적을 요청하고, 예산 담당자 승인을 확인한 후, 소싱 전에 요청을 재무팀으로 라우팅합니다.
Run once 검증을 활성 워크플로로 전환하기 전에 작업 사용량, 웹훅 담당자, 시나리오 일정을 검토하세요.
기록 반영 실패를 재시도하거나 수동 검토 경로로 이동할 수 있도록 HTTP 모듈 주변에 오류 처리기를 추가하세요.
Jodoo 레코드
워크플로 실행 후 Jodoo는 요청자 이름, 부서, 요청일, 우선순위, 품목 카테고리, 품목 설명, 수량, 예상 단가 등 지속적으로 관리할 구매 요청 필드를 유지합니다.
실제 테스트 실행
스크린샷은 합성 데이터를 사용하며 Make 설정, 성공적인 실행, 워크플로로 생성된 Jodoo 행을 보여줍니다.

Make Custom webhook이 샘플 페이로드를 수신하고 HTTP 모듈이 구조화된 필드를 Jodoo로 전송합니다.

Make 실행 기록에는 HTTP 모듈 완료, 작업 세부정보, Jodoo 데이터 ID 응답이 표시됩니다.

구매 요청 승인 라우팅이 Jodoo에 기록되었으며 요청자 이름, 부서, 요청일, 우선순위, 품목 카테고리, 품목 설명 필드가 표시됩니다.
FAQ
Jodoo 레코드, 워크플로, 앱 템플릿과 에이전트 플랫폼을 함께 사용하는 방법에 대한 답변입니다.
예. 이 검증은 합성 데이터, 실제 Make 실행, 검증 매니페스트가 포함된 확인된 Jodoo 기록 반영 스크린샷을 사용했습니다.
시각적인 시나리오 캔버스, Run once 테스트, 모듈 기록을 원하는 운영팀에 Make가 적합합니다. 이후 Jodoo는 검토와 후속 조치를 위한 지속적인 레코드를 유지합니다.
공개 검증은 Make Run once 모드를 사용하므로 캡처된 스크린샷에서 시나리오 기록의 웹훅 번들, 모듈 버블, 작업 수, HTTP 응답을 확인할 수 있습니다. Custom webhook으로 시작하고, 샘플 요청을 붙여 넣은 다음, 의사결정 필드를 HTTP 모듈 본문에 매핑하기 전에 Make가 번들을 추론하도록 합니다. 구매 요청 승인 라우팅에서는 HTTP 모듈이 Jodoo에 기록하기 전에 Make 번들에서 요청자, 부서, 품목, 수량, 예상 총액, 예산 코드, 필요 기한, 누락 정보를 확인할 수 있어야 합니다.
Jodoo는 요청자 이름, 부서, 요청일, 우선순위, 품목 카테고리, 품목 설명, 수량, 예상 단가, 예상 총액, 필요 기한과 함께 감사 컨텍스트를 위한 원본 워크플로 출력을 저장합니다.
예. 검증된 합성 데이터 실행으로 시작한 뒤, 구매 요청 승인 라우팅 스키마가 안정화되면 양식, 포털, 받은편지함, API 또는 내부 시스템을 연결하세요. 고액 계약, 긴급 청구서, 정보 누락 사례에 서로 다른 Jodoo 대기열이 필요한 경우 기본 검증 후 라우터를 사용하세요.
워크플로가 의사결정 필드를 준비할 수 있지만, 담당자는 비즈니스 리스크, 결제 또는 법무 승인, 최종 운영 결정을 계속 검토해야 합니다. 웹훅 URL 담당자와 프로덕션 요청 데이터를 전달하는 모듈을 편집할 수 있는 사람을 문서화하세요.
다음 단계
검증된 Make 실행 1건으로 시작한 다음, 인접한 검토 대기열과 운영 업무 인계에 동일한 기록 반영 패턴을 재사용하세요. Run once 검증을 활성 워크플로로 전환하기 전에 작업 사용량, 웹훅 담당자, 시나리오 일정을 검토하세요.