Ramp's role model is additive by design
When finance and operations teams start building procurement workflows in Ramp, one of the first places they hit a wall is user permissions. The intuition — assign a custom role that restricts what an employee can do with a purchase order — turns out not to work the way you'd expect.
Ramp's permission system is additive. According to Ramp's roles and permissions documentation, a custom role is an add-on that gets assigned alongside a user's base role. The user retains everything the base role allows, and the custom role can only layer additional permissions on top. There is no mechanism within a custom role to revoke or restrict what the base role already grants.
The base Employee role cannot be removed
Every standard Ramp user must have exactly one base role: Admin, Owner, Bookkeeper, or Employee. Employee is the floor. According to Ramp's user roles documentation, you can upgrade a user to a higher base role, but all of those grant more permissions — not fewer. There is no tier below Employee, and no way to give a user only a custom role without a base role sitting underneath it.
This means that if the native Employee role is what's giving a user the ability to perform a certain action, assigning a custom role with that permission absent won't change anything. The base role wins.
This is also where teams who've worked in NetSuite first tend to notice the difference. In NetSuite, a custom role defines the complete permission set for a user — there is no mandatory base role sitting underneath adding permissions back in. Ramp works differently, and designing procurement controls without accounting for that distinction leads to gaps that don't surface until after go-live.
What base Employees can and can't do with POs
The good news is that procurement permissions in Ramp are largely additive from the Employee base role as well — meaning they have to be explicitly granted, not explicitly revoked. By default, a base Employee does not have the "Edit all procurement requests" permission. Without it, they cannot directly edit primary fields (vendor, amounts, line items, delivery dates) on an approved PO. Instead, any changes must go through a Change Order, which re-routes through the approval workflow.
To verify this is the case for your users, confirm at the role level:
- Go to Company → People → (...) Customize Role Permissions and open the Employee role.
- Under Procurement, confirm Edit all procurement requests is not checked.
- Confirm no custom role assigned to those users grants it either.
- Confirm the users are not on an elevated base role (Admin, Owner, Bookkeeper) — those bypass procurement permission gates entirely and can edit approved POs directly.
The exception that can't be configured away: PO ownership
Here's the part that matters most if your goal is tight PO controls: even when all of the above is correctly configured, there is one behavior that cannot be changed through role settings.
A user who submitted a PO can always cancel or close their own request. According to Ramp's support documentation, this is tied to being the request owner — not to any role permission — and it is not configurable. No role setting, custom or otherwise, removes a user's ability to act on a PO they personally submitted.
Change Orders: the right path for PO modifications
For everything else — editing primary PO fields after approval — the Change Order workflow is the correct mechanism. When "Edit all procurement requests" is absent from a user's effective permissions, attempting to directly modify an approved PO is blocked. The only path forward is submitting a Change Order, which:
- Can be submitted by the request owner, approvers, AP Clerks, and Admins
- Is only available when the PO is in Approved state — not while still in the approval queue
- Triggers the same approval workflow as the original PO by default, or a separate change order workflow if one has been configured in the Spend Program
- Maintains a full audit trail in the PO's activity history — every change, approval, and rejection is logged
To set up a dedicated approval workflow for change orders, navigate to the relevant Spend Program and toggle off "Use the same approval workflow for change orders" to define a separate policy.
Requesting the ability to remove the Employee base role
The structural gap here — no way to assign a user only a custom role, without the Employee base role layered beneath — is a known product limitation that Ramp is aware of. The use case is straightforward: finance teams that need to define a precisely scoped permission set for a class of user (for example, a procurement-only role that can submit but never close or cancel) currently can't do that cleanly in Ramp because the Employee base role adds permissions back in that can't be subtracted.
If your team has hit this limitation, it's worth formally requesting the enhancement directly through Ramp support. The more teams that surface the same gap, the more likely it is to move up the product roadmap. Note that Ramp's current process for product feedback does not include a formal tracking number or status updates — requests are passed to the product team and reviewed internally.
What's actually configurable today: a summary
| Scenario | Configurable in Ramp? |
|---|---|
| Prevent Employee from editing approved PO fields | Yes — ensure "Edit all procurement requests" is not granted |
| Require Change Order instead of direct edit | Yes — automatic when edit permission is absent |
| Separate approval workflow for Change Orders | Yes — configurable per Spend Program |
| Prevent submitter from closing/cancelling their own PO | No — tied to request ownership, not configurable |
| Assign a user only a custom role (no Employee base) | No — Employee base role is mandatory for all standard users |
| Custom role that subtracts Employee base permissions | No — custom roles are additive only |