Solution Handbook
A planning guide for the Make purchase request approval routing loop, including setup, Jodoo fields, proof record, and rollout notes.
Open handbookMAKE + JODOO
AI Purchase Request Approval Routing with Make + Jodoo
See how Make and Jodoo handle purchase request approval routing: review the source request, return structured decision fields, write the result into Jodoo, and keep owners, status, and next actions visible.
1
Review purchase request data with a consistent rubric
2
Write approval status, sourcing status, procurement owner, approval route, missing information, estimated total, priority, and recommended next action into Jodoo
3
Keep owner queues and follow-up status visible
4
Use Make proof before adapting the workflow to production sources
5
The public proof uses Make Run once mode so the captured screenshot can show the webhook bundle, module bubbles, operation count, and HTTP response in the scenario history.
VIDEO WALKTHROUGH
What happens in the Make demo
The video shows Make handling A field service team requests twelve rugged tablets with budget code, launch timing, estimated spend, and missing device-management details., then Jodoo storing the operational record.
Custom webhook receives the request
A field service team requests twelve rugged tablets with budget code, launch timing, estimated spend, and missing device-management details.
Make prepares structured review fields
The workflow keeps approval status, sourcing status, procurement owner, approval route, missing information, estimated total, priority, and recommended next action explicit instead of returning a loose paragraph.
HTTP module writes to Jodoo
The tested run sends the review output to Jodoo and receives a Jodoo data ID from the bridge.
Make proof stays inspectable
The public proof uses Make Run once mode so the captured screenshot can show the webhook bundle, module bubbles, operation count, and HTTP response in the scenario history.
Jodoo keeps the team record
The Jodoo app stores Requester name, Department, Request date, Priority, Item category, Item description, Quantity for review and follow-up.
DEMO SUMMARY
Make reviews the request, Jodoo tracks follow-up
This implementation fits operations teams that want a visible scenario canvas, Run once testing, and module history. The page keeps the visual scenario setup, the real run, and the Jodoo writeback visible. The HTTP module evidence is visual: method, endpoint, body type, parsed response, and completion status are all inspectable without opening a code editor.
Make scenario
A Make Custom webhook receives the sample payload and an HTTP module sends structured fields into Jodoo.
Structured decision
The workflow returns approval status, sourcing status, procurement owner, approval route, missing information, estimated total, priority, and recommended next action for Twelve rugged tablets for the field service team, including protective cases and device enrollment support..
Successful Make run
The Make run history shows the HTTP module completion, operation details, and the Jodoo data ID response.
Make implementation detail
Start with a Custom webhook, paste the sample request, and let Make infer the bundle before mapping the decision fields into the HTTP module body.
Purchase request recipe detail
For purchase request approval routing, the Make bundle should keep requester, department, item, quantity, estimated total, budget code, needed-by date, and missing information visible before the HTTP module writes to Jodoo.
Jodoo writeback
Jodoo stores the purchase request record and keeps the next action visible.
Operational follow-up
The recommended next action is to request a vendor quote, confirm budget owner approval, and route the request to Finance before sourcing.
Reusable kit
The takeaway kit includes a handbook, Jodoo field blueprint, and Make workflow recipe.
PLATFORM SETUP NOTES
What is specific to Make
The Jodoo record model can stay consistent, but each agent platform has a different build style, testing view, and production handoff.
Setup proof
The proof uses Run once so the incoming bundle and HTTP response are visible.
Action path
The HTTP module keeps method, URL, body type, and response parsing inspectable.
Recipe focus
Scenario history gives a visual record of operations, duration, and writeback response.
Production planning
Production planning should cover webhook ownership, routers, error handlers, and operation usage.
Evidence detail
The public proof uses Make Run once mode so the captured screenshot can show the webhook bundle, module bubbles, operation count, and HTTP response in the scenario history.
Run evidence
The HTTP module evidence is visual: method, endpoint, body type, parsed response, and completion status are all inspectable without opening a code editor.
Build detail
Start with a Custom webhook, paste the sample request, and let Make infer the bundle before mapping the decision fields into the HTTP module body.
Implementation path
Use a router after the base proof when high-value contracts, urgent invoices, or missing-information cases need different Jodoo queues.
Guardrail
Review operation usage, webhook ownership, and scenario scheduling before turning a Run once proof into an active workflow.
Review control
Add error handlers around the HTTP module so failed writebacks can be retried or moved to a manual review path.
Scenario recipe
For purchase request approval routing, the Make bundle should keep requester, department, item, quantity, estimated total, budget code, needed-by date, and missing information visible before the HTTP module writes to Jodoo.
Workflow adaptation
A router can split low-value requests, quote-required purchases, finance approvals, and urgent sourcing work after the first writeback proof is stable.
WORKFLOW KIT
Build the same purchase request approval routing loop
Review the handbook, copy the workflow recipe, and use the Jodoo field model when adapting the Make workflow.
REUSABLE WORKFLOW
The workflow decides. Jodoo keeps work moving.
- 01
Custom webhook
Starts the purchase request test with Twelve rugged tablets for the field service team, including protective cases and device enrollment support.. Start with a Custom webhook, paste the sample request, and let Make infer the bundle before mapping the decision fields into the HTTP module body.
- 02
Make scenario
A Make Custom webhook receives the sample payload and an HTTP module sends structured fields into Jodoo.
- 03
HTTP module
Sends structured JSON to the Jodoo writeback bridge. The HTTP module evidence is visual: method, endpoint, body type, parsed response, and completion status are all inspectable without opening a code editor.
- 04
Proof response
Shows the successful platform run and Jodoo data ID. The public proof uses Make Run once mode so the captured screenshot can show the webhook bundle, module bubbles, operation count, and HTTP response in the scenario history.
- 05
Jodoo queue
Stores fields for owner review, status tracking, and follow-up. Review operation usage, webhook ownership, and scenario scheduling before turning a Run once proof into an active workflow.
WORKFLOW LOOP
From Make purchase request approval routing to Jodoo
Custom webhook receives or starts the purchase request approval routing with synthetic data first.
Make applies a focused review instruction and returns approval status, sourcing status, procurement owner, approval route, missing information, estimated total, priority, and recommended next action.
HTTP module sends the structured output to the Jodoo writeback bridge and receives a data ID.
For purchase request approval routing, the Make bundle should keep requester, department, item, quantity, estimated total, budget code, needed-by date, and missing information visible before the HTTP module writes to Jodoo.
A router can split low-value requests, quote-required purchases, finance approvals, and urgent sourcing work after the first writeback proof is stable.
Scenario history is a strong proof point for procurement because it shows each module, operation count, response body, and accepted Jodoo data ID.
After proof, Make can add procurement notifications, finance approval branches, supplier quote lookups, and an error handler for failed writebacks.
Start with a Custom webhook, paste the sample request, and let Make infer the bundle before mapping the decision fields into the HTTP module body.
Use a router after the base proof when high-value contracts, urgent invoices, or missing-information cases need different Jodoo queues.
Jodoo creates the Purchase Request Form record and stores Requester name, Department, Request date, Priority, Item category, Item description, Quantity, Estimated unit price.
The team reviews the queue, assigns ownership, and completes the next action: request a vendor quote, confirm budget owner approval, and route the request to Finance before sourcing.
Review operation usage, webhook ownership, and scenario scheduling before turning a Run once proof into an active workflow.
Add error handlers around the HTTP module so failed writebacks can be retried or moved to a manual review path.
FIELD MAPPING
Agent output becomes Jodoo fields
| Agent or source data | Jodoo record fields |
|---|---|
| source request details | Requester name, Department, Request date, Priority |
| review decision fields | Quantity, Estimated unit price, Estimated total, Needed by date, Budget code |
| workflow response | Source platform, Original workflow output |
AGENT RECIPE
Prompt and structured output
Make role
Review one purchase request approval routing request and return structured fields that Jodoo can store, route, and report on. Start with a Custom webhook, paste the sample request, and let Make infer the bundle before mapping the decision fields into the HTTP module body.
Review instruction
Use the sample context for Twelve rugged tablets for the field service team, including protective cases and device enrollment support., decide approval status, sourcing status, procurement owner, approval route, missing information, estimated total, priority, and recommended next action, and keep the recommended next action specific. For purchase request approval routing, the Make bundle should keep requester, department, item, quantity, estimated total, budget code, needed-by date, and missing information visible before the HTTP module writes to Jodoo.
Writeback contract
Send a predictable JSON object through HTTP module; Jodoo should receive the same field names each run. Make is helpful when operations teams want to explain the handoff with a canvas, filters, routers, and module-level run history.
Required output
Return approval status, sourcing status, procurement owner, approval route, missing information, estimated total, priority, and recommended next action, source_platform, agent_confidence, and original workflow output for audit context.
Make controls
Review operation usage, webhook ownership, and scenario scheduling before turning a Run once proof into an active workflow. Add error handlers around the HTTP module so failed writebacks can be retried or moved to a manual review path. Document who owns the webhook URL and who is allowed to edit modules that carry production request data.
Purchase request implementation notes
For purchase request approval routing, the Make bundle should keep requester, department, item, quantity, estimated total, budget code, needed-by date, and missing information visible before the HTTP module writes to Jodoo. A router can split low-value requests, quote-required purchases, finance approvals, and urgent sourcing work after the first writeback proof is stable. Scenario history is a strong proof point for procurement because it shows each module, operation count, response body, and accepted Jodoo data ID. After proof, Make can add procurement notifications, finance approval branches, supplier quote lookups, and an error handler for failed writebacks.
{
"requester_name": "Avery Brooks",
"department": "Operations",
"item_category": "IT Equipment",
"item_description": "Twelve rugged tablets for the field service team",
"quantity": 12,
"estimated_total": 5820,
"needed_by_date": "2026-06-21",
"budget_code": "OPS-FIELD-2026",
"approval_status": "Pending Review",
"sourcing_status": "Needs Quote",
"approval_route": "Department manager then Finance",
"procurement_owner": "Procurement Operations",
"missing_information": "Confirm device management license count and delivery address",
"recommended_next_action": "Request a vendor quote and route to Finance before sourcing"
}JODOO STARTER APP
Purchase request starter app
Use the field model, views, and automations when adapting the purchase request approval routing workflow for your team.
Included fields
- Requester name
- Department
- Request date
- Priority
- Item category
- Item description
- Quantity
- Estimated unit price
- Estimated total
- Needed by date
- Budget code
- Business justification
- Approval status
- Sourcing status
- Procurement owner
- Approval route
- Missing information
- Recommended next action
- Original workflow output
Suggested views
- Needs procurement review
- Finance approval queue
- Needs quote
- High priority purchases
- All purchase requests
Automation rules
- Create a Jodoo record after Make returns structured output.
- Move high-priority or exception records into the right owner queue.
- Notify the suggested owner when missing information or hold reason is present.
- Keep the original workflow output in audit context.
ROLLOUT CHECKLIST
What to confirm before production
- Send synthetic data to the Custom webhook before activating the scenario.
- Reopen the HTTP module after edits and confirm the saved JSON mapping.
- Use scenario history to confirm status, operations, and response body.
- Add routers, filters, and notifications only after the base writeback is stable.
- Review operation usage, webhook ownership, and scenario scheduling before turning a Run once proof into an active workflow.
- Add error handlers around the HTTP module so failed writebacks can be retried or moved to a manual review path.
- Document who owns the webhook URL and who is allowed to edit modules that carry production request data.
- A router can split low-value requests, quote-required purchases, finance approvals, and urgent sourcing work after the first writeback proof is stable.
- Scenario history is a strong proof point for procurement because it shows each module, operation count, response body, and accepted Jodoo data ID.
- After proof, Make can add procurement notifications, finance approval branches, supplier quote lookups, and an error handler for failed writebacks.
Workflow kit
Keep the setup details for your team
Jodoo Starter App Blueprint
The Jodoo field model, recommended views, and automation ideas for adapting the Purchase Request Form.
Open blueprintAgent Prompt + Workflow Recipe
The Make setup, output contract, endpoint notes, and test-run recipe used for this writeback proof.
Open recipeWORKFLOW
From Make purchase request to Jodoo record
Make handles the visual scenario; Jodoo keeps the record teams can filter, assign, and review.
Custom webhook receives or starts the purchase request approval routing with synthetic data first.
Make applies a focused review instruction and returns approval status, sourcing status, procurement owner, approval route, missing information, estimated total, priority, and recommended next action.
HTTP module sends the structured output to the Jodoo writeback bridge and receives a data ID.
For purchase request approval routing, the Make bundle should keep requester, department, item, quantity, estimated total, budget code, needed-by date, and missing information visible before the HTTP module writes to Jodoo.
A router can split low-value requests, quote-required purchases, finance approvals, and urgent sourcing work after the first writeback proof is stable.
Scenario history is a strong proof point for procurement because it shows each module, operation count, response body, and accepted Jodoo data ID.
After proof, Make can add procurement notifications, finance approval branches, supplier quote lookups, and an error handler for failed writebacks.
Start with a Custom webhook, paste the sample request, and let Make infer the bundle before mapping the decision fields into the HTTP module body.
Use a router after the base proof when high-value contracts, urgent invoices, or missing-information cases need different Jodoo queues.
Jodoo creates the Purchase Request Form record and stores Requester name, Department, Request date, Priority, Item category, Item description, Quantity, Estimated unit price.
The team reviews the queue, assigns ownership, and completes the next action: request a vendor quote, confirm budget owner approval, and route the request to Finance before sourcing.
Review operation usage, webhook ownership, and scenario scheduling before turning a Run once proof into an active workflow.
Add error handlers around the HTTP module so failed writebacks can be retried or moved to a manual review path.
JODOO RECORD
What Jodoo stores
Jodoo keeps the durable purchase request fields after the workflow runs: Requester name, Department, Request date, Priority, Item category, Item description, Quantity, Estimated unit price.
Requester nameDepartmentRequest datePriorityItem categoryItem descriptionQuantityEstimated unit priceEstimated totalNeeded by dateBudget codeBusiness justificationApproval statusSourcing statusProcurement ownerApproval routeMissing informationRecommended next actionOriginal workflow output
REAL TEST RUN
A Make workflow wrote the purchase request into Jodoo
The screenshots use synthetic data and show the Make setup, a successful run, and the Jodoo row created by the workflow.
Make scenario configuration
A Make Custom webhook receives the sample payload and an HTTP module sends structured fields into Jodoo.
Successful Make run
The Make run history shows the HTTP module completion, operation details, and the Jodoo data ID response.
Jodoo writeback
The purchase request approval routing was written into Jodoo with Requester name, Department, Request date, Priority, Item category, Item description fields visible.
FAQ
Common questions
Answers about using agent platforms with Jodoo records, workflows, and app templates.
Was this Make purchase request approval routing tested end to end?
Yes. The proof used synthetic data, a real Make run, and a verified Jodoo writeback screenshot with a proof manifest.
Why use Make for purchase request approval routing?
Use Make when operations teams that want a visible scenario canvas, Run once testing, and module history. Jodoo then keeps the durable record for review and follow-up.
How is this Make implementation different from the other platform examples?
The public proof uses Make Run once mode so the captured screenshot can show the webhook bundle, module bubbles, operation count, and HTTP response in the scenario history. Start with a Custom webhook, paste the sample request, and let Make infer the bundle before mapping the decision fields into the HTTP module body. For purchase request approval routing, the Make bundle should keep requester, department, item, quantity, estimated total, budget code, needed-by date, and missing information visible before the HTTP module writes to Jodoo.
What does Jodoo store after the workflow runs?
Jodoo stores Requester name, Department, Request date, Priority, Item category, Item description, Quantity, Estimated unit price, Estimated total, Needed by date, plus the original workflow output for audit context.
Can this connect to production source data later?
Yes. Start with the verified synthetic run, then connect forms, portals, inboxes, APIs, or internal systems once the purchase request approval routing schema is stable. Use a router after the base proof when high-value contracts, urgent invoices, or missing-information cases need different Jodoo queues.
What should stay reviewed by the team?
The workflow can prepare the decision fields, but owners should still review business risk, payment or legal approval, and final operating decisions. Document who owns the webhook URL and who is allowed to edit modules that carry production request data.
NEXT STEP
Turn purchase request into tracked follow-up
Start with one verified Make run, then reuse the same writeback pattern for adjacent review queues and operational handoffs. Review operation usage, webhook ownership, and scenario scheduling before turning a Run once proof into an active workflow.