Pipefy: 7 Controls for Purchase Requests and Approval Workflows

Pipefy is a process automation platform that helps teams organize requests, move work through stages, and coordinate actions across people and systems. For purchasing, that can mean turning an informal request into a visible process with clear information, approval, and follow-up. The benefit depends on the rules around the workflow as much as the form itself.

This guide explains Pipefy’s basic process model and seven controls to test for purchase requests. It covers intake, routing, authority, supplier data, integrations, exceptions, and reporting, followed by a practical pilot that exposes common approval problems.

How does Pipefy organize work?

In Pipefy, a pipe represents a process and cards represent pieces of work moving through it. The official guide to pipes explains how phases and fields structure that work. A purchase request can therefore have a record that moves from intake through review to an agreed outcome.

The Pipefy purchasing approval guide describes an approach to automated approval flows. Use it as a starting point, then test the rules your own organization needs.

For example, a technician may request a replacement tool. The request needs a purpose, cost, delivery need, and budget owner. Approval may authorize a purchase, but it does not by itself prove that someone placed the order, received the item, or paid the invoice.

Define those boundaries before building. Pipefy may coordinate the workflow while an ERP or accounting system remains responsible for purchasing and financial records. Confirm the exact product package and connections in the proposal.

1. Collect enough information for a real decision

Start with the facts an approver needs: requester, business purpose, item or service, quantity, expected cost, required date, and budget context. Next, identify which fields depend on the request type.

A routine stock request may need a known item code. A new service may need a scope and supplier quote. Forcing both through one long form can create irrelevant answers and make users work around the process.

Test the intake with someone who does not know the setup. Ask them to submit a normal request and an unusual one. Then have the approver explain the decision they can make from the information provided.

Anomoz’s purchase requisition guide provides a useful starting point for required fields and handoffs. Adapt the fields to your purchasing policy rather than copying a template without review.

Also handle incomplete requests honestly. A missing quote should create a clear request for information, not a false approval or an unexplained rejection. Assign the next action so the requester knows how to proceed.

2. Route requests using explicit business rules

Approval routes often depend on amount, department, purchase type, or risk. Write each rule in plain language before implementing it. Next, identify where rules overlap or leave a gap.

For example, a request may need both a budget owner and a technical reviewer. Decide whether their reviews happen in sequence or together and what happens when one asks for changes. A process should not move forward merely because the easier review finished first.

Test boundary values. If a different route starts above a set amount, check values below, at, and above the threshold. Also include tax, currency, and total-versus-line decisions where those affect policy.

Anomoz’s conditional logic guide explains how business conditions can shape forms and approvals. Keep the logic readable so staff can explain a route without opening a hidden technical rule.

Finally, test missing or unexpected values. A blank department or unrecognized category should reach review rather than silently follow a default route that grants more authority than intended.

3. Preserve authority when people and amounts change

A workflow needs to know who can approve, not just who receives a message. Define authority by role or policy and plan for staff changes. Next, decide how temporary delegation works during leave.

Test a requester who also holds an approval role. The process should follow the company’s self-approval policy rather than assume that matching a name makes the decision valid. Keep request, approval, and payment responsibilities clear.

Anomoz’s segregation of duties guide offers practical questions for those boundaries. Ask the implementation team to demonstrate the controls in the specific Pipefy setup under consideration.

Then change the amount after an approval. A request that doubles in value may need a new decision, while a small descriptive correction may not. Write the rule and test which changes reset or preserve prior approval.

Also keep the decision context. An authorized reviewer should be able to see what the approver considered, when they acted, and why the request advanced. Confirm the required history and reporting behavior in your chosen plan.

4. Keep supplier information separate from purchase permission

An approved request does not prove a supplier is ready to use. The business may need supplier validation, commercial terms, delivery details, or an onboarding review. Define when those checks occur and who owns them.

Next, distinguish an existing supplier from a new one. A new supplier request may need a separate review before the purchasing team acts. Do not let a free-text name silently become an approved supplier master record.

For example, a requester may attach a quote from a company with a similar name to an existing supplier. Staff should verify identity through the approved process rather than match on name alone.

Also protect sensitive supplier information. A general purchase card may not be the right place for bank details or personal documents. Use the approved system and access controls for those records, with references where the workflow needs them.

Finally, test a supplier change after approval. A lower price from a different provider may alter more than the amount. The decision might need to consider service scope, risk, and terms again.

5. Connect approved work to the next system safely

Decide what happens after approval. Does a buyer place an order manually, does a connection create a draft order, or does the workflow send data for another review? Keep that handoff explicit.

Next, map each field to its destination. Supplier ID, item code, quantity, cost center, currency, and approval reference should mean the same thing in both places. A successful transfer does not prove the business record is correct.

Use a stable request reference so staff can trace the same action across systems. Then repeat a test message and interrupt the connection. Confirm how the process avoids duplicate orders and finds work that never reached the destination.

Also distinguish “sent” from “accepted.” A workflow may have attempted a handoff while the receiving system rejected a field. Give the exception an owner and preserve enough evidence to reconcile the records.

If an unusual customer or operational workflow needs a tailored interface, custom crm development may help connect that work. Keep the source of truth for orders and financial data clear so the custom layer does not create competing records.

6. Design rejection, changes, and cancellation paths

A purchase workflow needs more outcomes than approve or reject. A reviewer may need clarification, a requester may change scope, or the business may cancel after placing an order. Model those cases before launch.

For a clarification request, show who must respond and what information remains missing. Next, decide whether the request returns to the same reviewer or starts routing again after a material change.

For rejection, record a reason that helps the requester understand the outcome. Avoid a generic status that leads them to submit the same request again. If a revised request is allowed, keep its relationship with the earlier decision clear.

Cancellation deserves its own test. Cancelling a card does not necessarily cancel an order already sent to a supplier. The process should check downstream commitments and confirm the result before treating the work as finished.

Also test urgent exceptions. If company policy permits an emergency route, give it explicit authority and a later review where required. A permanent bypass labeled “urgent” can undermine every normal approval rule.

7. Report waiting time and outcomes with clear definitions

A useful dashboard helps someone decide what to do. Start with requests waiting for information, approvals awaiting action, failed handoffs, and work approved but not yet ordered. Next, assign an owner to each queue.

Define when the clock starts and stops. A total cycle time can include time waiting for the requester, reviewer, buyer, or supplier. Separating those stages makes the next improvement more specific.

Also distinguish approved value from committed spend and paid cost. Those numbers represent different points in the process. A report can mislead budget owners if it presents all three as the same measure.

For a hypothetical monthly review, an approval delay might fall while the approved-to-order backlog grows. The process improved one stage but still leaves the business waiting. Review the whole journey before declaring success.

Finally, inspect the actual records behind a dashboard total. Pick several requests and trace their route, changes, and outcome. This validates that the metric reflects business events rather than merely card movement.

A practical purchasing pilot

Choose one department and a bounded purchase category. Include a routine request, a request above an approval threshold, a new supplier, missing information, and a cancellation. Next, follow each through the next system or manual purchasing step.

Before starting, record the current pain points and baseline. These might include incomplete forms, unclear authority, repeated follow-up, or orders created twice. Measure those problems during the trial rather than choosing a generic automation target.

Ask a colleague who did not build the workflow to handle an exception using the guide. If they need hidden knowledge, improve the instructions or simplify the route. A process should remain usable when its designer is away.

Then review the configuration with procurement, finance, and the department owner together. They may interpret approval, commitment, and completion differently. Resolve those differences before expanding to more teams.

Cost, access, and ongoing change

Request current pricing for the users, guests, processes, automation volume, integrations, and controls you need. Confirm which functions appear in the actual offer. Include setup, training, data cleanup, support, and future changes in the ownership estimate.

Also plan who maintains approval rules when staff, budgets, or policies change. Use a test environment or another controlled review method suited to the setup before changing live behavior. A small rule edit can route real spending differently.

Finally, review access and exports. Confirm what requesters, reviewers, administrators, and integration accounts can see and change. Ask for a sample export that preserves the history your business needs for later review.

When a simpler workflow may be enough

A small team with a few low-risk requests may need a lighter process than a broad automation rollout. Compare the effort of maintaining the rules with the problem they solve. Start with a narrow workflow that people will actually use.

Conversely, a complex purchasing operation may need deep ERP controls or specialized procurement functions beyond a request board. Evaluate those requirements directly. Pipefy should earn its role through a clear boundary and a proven handoff.

Make approvals produce a clear next action

Pipefy can help make purchase requests visible and repeatable when the business defines its rules first. Prove intake, authority, changes, handoffs, and exception handling through a small pilot. Expand when users can explain the decision and trace what happened after it.