Procurement Automation with Make.com: Design a Reliable Request and Approval Workflow

What procurement automation with Make.com should accomplish

A good procurement scenario does more than send a form response or create a notification. It creates a controlled path from purchasing need to approved business action.

The central design question is: what must be true before this request can move to the next state? For example, a request may need a valid cost center, a named budget owner, a clear business justification, and an approval appropriate to its value before it can become an order.

Make.com is well suited to coordinating the steps around that process. It can receive an event, transform and validate data, look up routing information, create or update records, send approval requests, and react to a decision. The system of record should still be chosen deliberately. A spreadsheet may support a small controlled process, while a procurement, finance, or operational database may be more appropriate when multiple people need reliable reporting and concurrent updates.

Define the procurement states before building the scenario

Start by describing the states a purchase request can occupy. Avoid using statuses that merely describe an activity, such as “email sent” or “form received.” A status should represent a meaningful business condition.

A useful starting sequence is:

1. Draft: the requester is preparing the information.
2. Submitted: the request has passed basic submission checks.
3. Needs information: a required field or supporting detail is missing.
4. Awaiting approval: the responsible approver must make a decision.
5. Approved: the request is authorized for the next purchasing step.
6. Rejected: the request cannot proceed under the current decision.
7. Ordered: a purchase order or equivalent supplier instruction exists.
8. Completed: the goods or service has been received and the process is closed.

Not every organization needs all of these states. The important point is to decide what each state means, which fields are required, who owns it, and what event permits a transition.

Design the request data model

Procurement automation becomes fragile when the form contains information that is not stored consistently or when later steps depend on fields that were never required at submission.

Separate information into four practical groups:

• Requester data: name, email, department, cost center, and manager or budget owner.
• Purchase details: item or service description, quantity, estimated price, currency, supplier, and required date.
• Decision data: approval route, approver, decision, decision date, comments, and any exception reason.
• Control data: request ID, current state, created date, last updated date, purchase order reference, and error status.

Use stable identifiers rather than relying on names or email addresses as the only way to find records. A request ID should travel through the form response, central record, approval message, purchase order, and notifications. This makes it easier to match a later approval response to the correct request.

Do not ask every requester to enter data that the system can look up reliably. For example, a department may determine the appropriate cost center or budget owner. A lookup can reduce inconsistent values, provided there is an accountable owner for maintaining the reference data.

Build the Make.com procurement scenario in controlled stages

Once the process and data model are defined, build the scenario in small stages. Each stage should have a clear input, an expected output, and a failure path.

1. Receive and normalize the request

The trigger may be a new form submission, a webhook, or a new record in another application. Immediately after the trigger, normalize values that will be used later. Dates should use a consistent format, amounts should be numeric, and choice fields should map to controlled values.

Keep the original submission available for reference, but create a clean operational record for routing and reporting. This distinction helps when a user provides free-text information that needs to be interpreted or corrected.

2. Validate before creating approval work

Validation should happen before an approver is asked to make a decision. Check that required data exists and that the request is internally coherent. Examples include a delivery date that is not earlier than the submission date, an amount that includes a currency, and a selected cost center that still exists.

When validation fails, do not create an approval task that cannot be completed. Set the request to “Needs information,” identify the missing field, and notify the requester or assigned coordinator. This prevents incomplete requests from disappearing into an approval queue.

3. Route according to maintained rules

Approval logic should be explicit. It may depend on amount, department, cost center, spend category, supplier risk, project, or whether the purchase is an exception to an existing policy.

A simple rule might route a request to the budget owner first and require an additional approver above a defined internal threshold. The threshold itself should live in a maintained configuration table or policy record where its owner is clear. Hard-coding scattered thresholds into multiple filters makes future changes difficult to audit.

Also define what happens when the lookup fails. A missing approver should create an exception for procurement or operations, not silently route the request to a generic mailbox.

4. Record approval decisions as business data

An approval is not complete merely because an email was sent. The workflow needs a reliable way to capture the response and associate it with the correct request ID. Store the decision, decision maker, timestamp, comments, and resulting state.

Use separate paths for approval, rejection, and unresolved outcomes such as expiration or technical failure. A rejected request should remain visible with a reason where available. A failed automation should be distinguishable from a declined purchase so that operational teams do not confuse system errors with business decisions.

5. Create the next purchasing action

After approval, the scenario can create or update a purchase order record, pass structured information to a finance system, or notify the procurement team that supplier communication is ready. The correct next action depends on the organization’s controls and the system that owns purchase orders.

Do not create a supplier-facing purchase order solely because a request reached an “approved” status if additional checks are still required. Define whether approval authorizes the purchase, authorizes procurement to prepare the order, or authorizes a separate finance step.

Make ownership visible at every handoff

Every active procurement request should have an owner, even when Make.com performs the next automated action. Ownership answers the question: who is responsible for resolving the request if the normal path stops?

• The requester owns the accuracy of the business need.
• The budget owner owns authorization within the relevant budget.
• Procurement owns supplier and purchasing actions where applicable.
• Finance owns financial controls that are outside procurement authority.
• The automation owner owns scenario reliability, error handling, and monitoring.

These roles may belong to the same person in a small organization, but they should still be distinguishable. A notification should identify the required action, the deadline or expected response where relevant, the request ID, and the location of the source record.

Operational observation: A notification is not a handoff unless it identifies the next owner and the business decision that owner must make.

Test failure paths, not just successful requests

Testing a low-value request that passes every rule proves only that the happy path works. Procurement scenarios need tests for incomplete data, invalid reference values, missing approvers, duplicate submissions, rejected requests, delayed responses, and downstream connection failures.

Idempotency is especially important. If the same trigger is processed twice, the scenario should recognize the existing request ID or event identifier rather than creating duplicate records or duplicate supplier instructions.

Review execution history during testing, but also decide how the live process will be monitored. Someone should be able to identify failed runs, requests waiting too long, and records with inconsistent states without inspecting every execution manually.

Example: a controlled request-to-order flow

Consider a hypothetical company where an employee needs software for a project. The employee submits the item, business justification, estimated annual cost, project code, and desired start date. Make.com creates a request record and looks up the project’s budget owner.

The validation path confirms that the project code is active and the amount includes a currency. Because the request exceeds an internal threshold, the workflow routes it to the budget owner and then to procurement. If the budget owner rejects it, the request becomes “Rejected,” the reason is stored, and the requester is notified. If it is approved, procurement receives a structured record with the request ID and can create the next purchasing document according to its own controls.

This example works because each transition has a defined condition and owner. The automation is not deciding whether the software is valuable. It is making the agreed decision process consistent and visible.

Connect procurement automation to broader operations

Procurement data often affects finance, project delivery, supplier management, inventory, and reporting. Before adding more integrations, decide which system owns each business record and which events should be shared.

For example, the procurement system may own the request and approval state, while finance owns payment status. A project system may need the approved commitment, but it should not become a second source of truth for approval decisions. Clear ownership prevents conflicting updates and makes reporting easier to interpret.

For organizations connecting procurement with wider operational data, a connected platform can bring finance, purchasing, supply chain, and reporting information into a clearer operating view. ConsultEvo’s commerce and operations intelligence platform example is relevant as a reference for thinking about connected operational systems, without assuming that every organization needs the same architecture.

If the process spans several applications, the work is usually larger than configuring one scenario. It may require data model design, ownership decisions, exception handling, and integration governance. ConsultEvo provides systems, operations, automation, and AI implementation services for this type of process-led work.

When to improve the workflow

After launch, use operational signals to decide what needs attention. Useful questions include: Which requests remain in “Needs information” most often? Which approval routes generate the most delay? Which reference data causes validation failures? How many records require manual correction? Are people using the system states consistently?

These questions are more useful than measuring the number of modules in a Make.com scenario. A shorter scenario is not automatically better, and a more complex one is not automatically more capable. The goal is a reliable procurement process with cleaner data, clearer ownership, and better decisions.