Configuring Procurement Workflows

Note: This article covers how to build and configure procurement approval workflows within Spend Programs. If you're looking for general information about creating and managing Spend Programs, see Get started with Procurement.

Overview

Procurement workflows let you define what happens when an employee submits a spend request — who needs to approve it, what information is collected, and which external tools are involved. Each workflow is attached to a Spend Program and runs automatically from the moment a request is submitted until the card or purchase order (PO) is approved.

Note: These steps require access to Procurement workflows. If you cannot access them, ask your Ramp administrator to check your organization's access.

You build workflows using the Workflow Builder, a visual drag-and-drop canvas. Each step in your workflow is a node on the canvas, and you connect them to define the order of execution. No code required.

How it works

Step 1: Open the workflow builder

1. Open your procurement Programs list under Manage spend or Procurement, depending on your setup. See Find Procurement in Ramp for navigation and access help.
2. Click Create program or select an existing program.
3. If creating a new program, choose a purchase-order or approval-only starting point under Start from scratch, or select a template.
4. For an existing program, choose the entry path for the workflow you want to configure:
   • Initial requests with a saved workflow: Open the program's row menu and select Edit approval workflow. For a default policy, select Edit default policy instead.
   • Purchase-order change orders: Open the program's row menu and select Edit, then find Who approves change orders?. To configure a separate workflow, turn Use the same approval workflow for change orders off. For import-only programs, turn Require approval for change orders on instead. If an editor choice appears, select Edit current workflow to edit the existing policy. Select Edit on the saved workflow preview.
   • No saved initial-request workflow (purchase-order programs): Open the program's row menu and select Edit. Under Who approves requests?, open Approval policy and select Create new approval policy for "[program name]" or Create new approval policy for this program.
   • No saved change-order workflow: Open the program's row menu and select Edit. Under Who approves change orders?, enable separate approvals as described above. Open Change order approval policy and select Create new change order approval policy for “[program name]” or Create new change order approval policy for this program.

You need permission to edit the workflow and, for paths through Edit, the program. If you cannot edit it, ask a workflow administrator to make the change. The editor depends on the program's policy; creating a policy does not always open the canvas editor. The steps below describe the canvas editor.

For AI-assisted workflow editing, use Edit with Ramp in the approval or change-order workflow builder. See Create and edit Spend Programs with AI for availability, permissions, and review steps; agent-made workflow changes can save as a draft immediately.

Step 2: Understand the canvas

The builder opens as a full-screen canvas with two nodes already in place:

• Trigger — The event that starts the workflow (for example, "Procurement requested"). Ramp sets this automatically based on the workflow type, and you cannot edit it.
• Outcome — The final step that approves the card or PO once all preceding steps are complete.

You add steps between these two nodes to build your approval process.

Step 3: Add steps

Click the + icon between any two nodes to insert a step. For the full list of available steps, see Available step types.

Step 4: Configure each step

Click any step to open its configuration panel on the right side of the screen. Each step type has its own options. See Configuring steps for details on the most common configurations.

Step 5: Test your workflow

Click Test in the right hand upper corner to test your workflow before publishing. You can select a recent PO or enter sample data to see which path a request takes, which steps execute, and the estimated approval time. If your workflow uses workflow blocks, they expand automatically during simulation so you can trace the full path.

Testing does not run Agent review steps, and you cannot enter sample agent outputs. If a Split paths condition depends on an agent's outputs, the test cannot determine which path the request takes, so those paths may appear unresolved or as if more than one path runs. Agent outputs exist only when the workflow runs on a submitted request; you can then follow its path with workflow progress tracking. For conditions based on Send custom form responses, you can enter sample answers when you create sample data.

Step 6: Save and publish

Click Save to save your workflow. Return to the program editor and finish publishing your changes.

New requests follow the updated workflow. Requests already in progress continue using the version that was active at the time of submission.

Ramp keeps a history of published versions so you can review how your workflow has changed over time.

Available step types

When you click + to add a step, you can choose from the following categories.

Approvals and notifications

Conditional logic

Data collection

Workflow management

Integrations

Note: Integration steps become available after you enable the corresponding integration in your Ramp account. Open Integrations to add, search for, or see all integrations. The Custom API workflow step doesn't have an Integrations entry. Ramp currently turns it on for your business. To get access, contact your Ramp account manager or Ramp Support.

AI-powered steps (agents)

See Get started with Ramp Procurement agents.

Configuring steps

Click any step to open its configuration panel. Below are the key options for the most commonly configured step types.

Require approval

For First matching manager (Alpha) setup, including condition matching and no-match routing, see First matching manager approvals.

• Approval type:
  • Require any — At least one person from the selected approvers must approve. For clear ownership, see Randomly assign (Beta).
  • Require all — Every selected approver must approve.
  • Require multiple (Beta) — Require a set number of approvals before proceeding. See availability, setup, and counting rules.
  • Randomly assign (Beta) — Assign one person from the selected users and groups to own the approval. See Configure Randomly assign and review task behavior.
• Approvers — Select specific users, fixed groups (for example, "Finance Team"), or relative groups (for example, "Department Manager" or "Location Manager").
• Deadline (SLA) — Set a service-level agreement (SLA) due date for the approval (for example, "Due in 3 business days"). This can override the program's default SLA.
• Instructions — Add instructions displayed to the approver (up to 1,000 characters).
• Tasks (checklist) — Add a checklist of items the approver must complete (for example, "Verify contract terms"). You can mark items as required. Up to 20 items.
• Separation of duties — Control whether requesters can approve their own requests. Only Owners can change this setting.

Split paths

• Execution type:
  • First true path — Evaluates conditions left to right and runs only the first matching branch.
  • All true paths — Runs every branch that evaluates to true in parallel.
• Conditions — Each path has one or more conditions, and they all use the same join type: all must match (AND), or any can match (OR). Changing the join on one condition changes it for every condition in that path, so you can't combine AND with OR within one path, such as (A OR B) AND C.
• Operators: is, is not, is greater than, is less than, is greater than or equal to, is less than or equal to, is between, is set, is not set.
• Available condition fields:
  • Request data: amount, vendor type (new or existing), request type (new, renewal, expansion), department, location, business entity.
  • User data: requester's role (Admin, Manager, Employee, Finance admin, and others), department, custom user fields.
  • Accounting data: tracking category selections.
  • Vendor data: Vendor group, which checks whether the request's vendor belongs to any of the vendor custom groups you select (includes any of). A request for a new vendor that isn't in Ramp yet doesn't belong to any group.
  • Upstream data: responses from custom forms or AI agent reviews earlier in the workflow.
• Fallback: Add an "Otherwise" path that runs when no other conditions match.
• Limits: By default, you can add up to 30 paths per split node and up to 10 levels of Split paths steps nested inside one another. Some accounts have higher limits. On the canvas, Conditions limit reached appears when a split node has the most paths your account allows, and Nested limit reached appears when you can't nest another Split paths step.

Send custom form

• Select an existing workflow form or create a new one.
• Assign specific users or groups to fill out the form.
• Available field types: text, paragraph, number, date, email, link, file upload, address, monetary amount, yes/no, vendor selector, department selector, contact selector, merchant, and merchant category.
• You can map form questions to core system fields (for example, mapping a "Net Terms" question directly to a vendor's payment terms).

For more information see Send follow-up forms in procurement workflows.

Request vendor information

• Welcome message — Add instructions or a welcome message for the vendor.
• Payment details — Request bank account information, with an option to require bank account confirmation.
• Tax details — Request W-9 or other tax documentation.
• Business verification — Run a screening on the vendor's business.
• Custom forms — Create additional forms for the vendor to complete.
• Require completion — Block the workflow from continuing until the vendor completes all selected forms.

Workflow blocks

• Select from existing workflow blocks or create new ones.
• You can expand blocks on the canvas to view their internal steps, or collapse them into a single node for a cleaner view.
• Editing the source workflow block automatically updates every workflow that references it.
• You cannot place integration nodes or nested workflow blocks inside a workflow block.

Workflow triggers

The trigger is the first node in your workflow and fires automatically based on the workflow type. You cannot edit triggers.

Workflow progress tracking

Once a procurement request is submitted, both submitters and reviewers can track its progress:

• Visual workflow diagram — Shows the current status, including which step is pending and who needs to act.
• Time tracking per step — Shows how long each step is taking so you can identify bottlenecks.
• Completed and upcoming steps — View which approvals and actions are complete and what's next in the workflow.

Use cases and examples

• Scenario: “Team software and small tools under $500”
  • A company wants employees to move quickly on everyday tools, while still keeping spend visible to the budget owner.
  • Trigger: A requester submits a purchase request for a non-catalog item.
  • Condition: If the request total is under $500 (or whatever threshold fits your policy).
  • Approvals: Route to one approver (often the requester’s direct manager or cost center owner).
  • Outcome: Once approved, the request can move straight to PO creation or purchasing.
  • Real-world example:
  • A Marketing Coordinator needs a $240 one-year subscription for a design plugin. They submit a request coded to “Marketing – Tools.” Because it is under $500, it goes only to the Marketing Manager for approval. The manager approves the same day, and the purchase proceeds without Finance or Procurement getting pulled in.
• Scenario: “New SaaS vendor, $50k annually, requires security sign-off”
  • A company wants to ensure high-value purchases and new vendors are reviewed by the right teams, without turning it into a slow, fully sequential chain.
  • Trigger: A requester submits a high-value purchase request for a new vendor .
  • Conditions:
    • Amount is over $25,000 (example threshold)
    • Vendor is new (not already onboarded / not an approved vendor)
  • Approvals (in parallel):
    • Finance (budget and terms)
    • Department leader (business justification)
    • Security/IT (security questionnaire, SSO requirements, data handling)
    • Procurement/Vendor onboarding (W-9, banking/payment method, compliance checks)
  • Outcome: The request only moves forward once all parallel approvers have signed off, then Procurement can finalize onboarding and purchasing.
  • Real-world example:
  • Data Science requests a new analytics platform for $60k per year. The tool will store customer data, so Security must review. As soon as the request is submitted, the approvals fan out:
  • Finance confirms budget availability and pushes for annual prepay discount terms.
  • Security sends a standard security questionnaire and confirms SOC 2 coverage.
  • Procurement starts onboarding (tax form, payment details, vendor record setup).
  • Because these happen in parallel, Procurement is not waiting for Finance to finish before starting onboarding, which can save multiple days.

Best practices and tips

• Name your steps clearly — Clear names help you track workflow progress and make the canvas easier to understand at a glance.
• Include instructions for approvers — Add context so reviewers know exactly what to look for.
• Use parallel paths to reduce approval time — When multiple departments need to review simultaneously, use All true paths in a Split paths node.
• Standardize with workflow blocks — Reuse common processes (like security reviews or legal approvals) across Spend Programs to keep them in sync.
• Test before publishing — Use Test to catch logic errors before your workflow goes live.
• Set deadlines — Add SLAs to approval steps to keep requests moving and create accountability.
• Reference upstream data in conditions — Route requests based on responses from earlier custom forms or AI agent reviews.

Frequently asked questions

Can I have multiple workflows for different Spend Programs?

Yes. Each Spend Program has its own workflow. You can configure different approval logic, integrations, and conditions for each program.

What happens to in-flight requests when I publish a new workflow version?

Requests already in progress continue following the workflow version that was active when they were submitted. Only new requests use the updated workflow.

Can I reuse workflow logic across programs?

Yes. Use Workflow blocks to define reusable sets of steps shared across multiple Spend Programs. Changes to a workflow block automatically propagate everywhere it's used.

Can workflows branch into multiple parallel paths?

Yes. Use the Split paths step with the All true paths execution type. Every branch whose condition evaluates to true runs in parallel.

What integrations are supported?

Ramp supports Ironclad, SpotDraft, LinkSquares, DocuSign, Dropbox Sign, Jira, Asana, Linear, Vanta, OneTrust, LogicGate, Drata, Lema AI, Slack, and custom API workflows. You must enable the corresponding integration in your Ramp account before it appears in the Workflow Builder. The Custom API workflow step doesn't have an Integrations entry. Ramp currently turns it on for your business. To get access, contact your Ramp account manager or Ramp Support.

How do Policies work?

Policies can automatically do the upfront research in an approval workflow, like pulling in relevant context, checking policy, and summarizing risk so approvers do not have to start from scratch. Based on the policy’s outcomes, you can conditionally route the request to the right next approvers, and show downstream approvers the policy’s results so the decision trail is consistent and transparent.

Can I test my workflow before publishing?

Yes. Use the Test feature to test your workflow with a real PO or sample data. The test shows which path a request takes and provides an estimated approval time. It does not run Agent review steps, so it cannot confirm paths that depend on agent outputs. See Test your workflow.

What triggers are available?

Procurement workflows support these triggers: Procurement requested, Change order requested, Approval requested, RFX requested, and Sourcing event requested. Ramp sets triggers automatically based on the workflow type, and you cannot edit them.

Is there a limit to how complex my workflow can be?

By default, you can add up to 30 paths per split node and nest Split paths steps up to 10 levels deep. Some accounts have higher limits; see Split paths for how to tell when you've reached yours. You cannot place integration nodes or nested workflow blocks inside a workflow block.