Raley Procurement vs. build it yourself in JSM (and the Jira procurement template)

If your company runs on Atlassian, sooner or later someone asks the obvious question: why not run procurement in Jira too? The work is already happening there. Your teams already know the interface. Jira even ships a procurement template, and Jira Service Management (JSM) is famously flexible. So the instinct to build purchasing approvals yourself is a good one.

The harder question is not whether you can build it. You almost certainly can. It is whether building and maintaining it yourself costs less, over the years, than installing a purpose-built app such as Raley Procurement. This article lays out both paths, with a feature-by-feature comparison, so you can make the call for your own situation.

The short answer

Build it natively when a purchase request is one form, one approver, and the issue key is a fine PO number. Buy an app when you need multi-line orders coded to cost centers, a product and supplier catalog, approval routing that changes with amount and department, and a PDF purchase order. We haven't mentioned the need to integrate with ERP yet... The dividing line is complexity, and complexity tends to grow.

First, which "template" are we talking about?

Two different things get called "the Jira procurement template", and they are not equal.

The first is Atlassian's Procurement template, a business project template for Jira itself, aimed at finance teams and described as a way to "track all purchases from request to receipt". It gives you a board, a list view, a form, a customizable workflow, and no-code automation. It is a tidy starting point for tracking purchases as tasks. It is not a procurement system: there are no order lines, no budgets, no suppliers, and no approval logic beyond what you wire up yourself.

The second is JSM, which does not ship a procurement template but does ship the building blocks: a customer portal, request types, forms, approval steps, Assets for reference data, and automation. This is the platform serious DIY builds are made on, and it is the platform Raley Procurement runs on top of. Our own view, argued in Jira vs JSM for procurement intake, is that JSM is the right Atlassian home for purchasing either way.

So the real comparison is three-way: the Jira template as shipped, a DIY build on JSM, and Raley Procurement on JSM.

What "build it yourself" actually means in JSM

"Build it in JSM" is not a switch you flip. It is an assembly project with several pieces you have to design, wire together, and then keep working through every Atlassian release:

1. A request type and form for purchase requisitions per category, plus a bunch of separate request types for the processes around it: new supplier onboarding, price changes, discounts, and edits to requests that are already locked.
2. A custom workflow with the right statuses, transitions, and post-functions to move a request from draft, through approval, to an issued PO.
3. A data model for cost-centers, gl-accounts, routings, suppliers, departments, and products, plus a way to connect each of those to the people and limits they belong to.
4. An approval engine that routes to the right approvers, in the right order, based on amount, department, budget, and supplier.
5. PO numbering, PDF generation, notifications, and reporting on top of all of it.
6. Integration with ERP

None of these is impossible. Several are deceptively hard and more sound like a solution project that can be outsourced to some Atlassian solution partner for implementation

Where building it yourself is the right call

Be skeptical of any vendor, Raley included, who tells you never to build anything. There are real cases where native JSM is the smart, cheap answer.

Simple, low-volume purchasing. If a requisition is essentially "describe what you want, get one manager's sign-off", a basic JSM request type with a single approval step does the job. You do not need an app for that.

Internally generated PO numbers. If you have no legacy numbering scheme, using the Jira issue key as the PO number is clean and free. This is one place DIY shines.

A single, stable approval path. If everyone routes to the same one or two approvers regardless of amount or department, native approvals plus an automation rule can handle it.

In-house Jira capacity. If you have admins who can treat the build as a maintained internal product rather than a one-time project, the ongoing cost is real but budgeted.

If most of those describe you, build it. An app's value shows up as complexity rises, so if your complexity is low, the math favors DIY.

Where building it yourself gets expensive

Procurement complexity tends to grow, and it grows in exactly the places JSM's native tooling runs thin. We wrote up the field detail in Procurement in Jira: 8 lessons from five years in the field; here is the short version.

Purchase request forms are harder than they look. A JSM form is a fixed set of fields. Out of the box, the portal does not offer "add another line" rows, so a request for five items becomes five copies of the same fields or a Marketplace grid app. Real purchasing also needs context the form cannot see: the requester's spending limit, the budget the line draws on, a searchable product list, and a cost center per line. The tempting shortcut, one sub-task per line item, leaves you keeping child issues in sync with a parent on totals and approvals.

Reference data needs a real home. A purchase request has to connect to suppliers, taxes, cost-centers, gl accounts, products and products. Forcing this into custom fields breaks down fast: departments cannot easily be tied to specific users, a supplier carries too much metadata for a select list, and a few thousand products in a dropdown is a usability disaster. The better pattern is JSM Assets. Since February 2026 Assets is included on the Standard plan with a 5,000-object allowance (Atlassian announcement), which removes the old Premium-only objection, but you still have to model the schema, sync it, and decide how much you sync. By the way, JSM Assets is a great place if you're in search of catalog purchases and need to store the items frequently requested.

Approval matrices are where most DIY builds stall. Real organizations approve by supplier, then product, then department, then routing by CC&GL, then ascending amount thresholds, and the approvers need to be asked in that order (the CEO should not be pinged before the VP and CFO have signed). JSM approval steps can take approvers from a user field or an Assets field, and amount-based branching can be built with automation. Encoding the ordering, then re-encoding it every time finance changes a threshold, is a standing maintenance job. Atlassian's own knowledge base documents a three-rule automation cascade just to refresh approvers when an Assets approver field changes (Atlassian support).

Edit-after-lock and auditability are easy to forget. Mistakes surface after a request has cleared a long approval chain. Most companies want a finance role that can correct a typo on a locked order rather than cancel and restart, and every such edit must be traceable: who changed what, when, with the old value preserved. That is real engineering, and it has to survive Jira upgrades.

PO numbers from another system add a layer. If purchase order numbers are issued by your finance system rather than by Jira, you need a custom field set by automation, a manual override for finance, and that number echoed onto whatever document goes to the supplier.

Individually, each of these is solvable. Collectively, they are a product. One you now own, staff, and maintain indefinitely.

Feature comparison: Jira template vs DIY on JSM vs Raley Procurement

Raley claims are checked against the Raley Procurement Marketplace listing, the product page, and the product docs as of September 2026. Atlassian columns are based on the Jira Procurement template page and JSM documentation as of the same date.

What a purpose-built app gives you

Raley Procurement exists to deliver the hard pieces above out of the box, while still living inside the JSM your teams already use. The pitch is not "replace Jira". It is "stop rebuilding the parts of procurement that are the same at every company".

Requesters raise a purchase request in the JSM portal, as a single item or as a multi-line order. Each line carries its cost center and GL account, a product from your catalog, and the budget it draws on. Approvals route by product, cross-functional reviewer, budget, CC, Gl, department, and spend tier, in the order your matrix defines. On approval the request becomes a purchase order with a branded PDF that stays on the same work item. And the same purchase order is sent to your ERP so, that the Finance and AP teams can continue there. Deliveries are recorded against it line by line in Raley or ERP.

Because it sits on top of JSM, you keep the flexible workflow underneath and can still shape transitions to match your process.

The trade-offs are the usual ones for any app: a per-user subscription, dependence on a third-party vendor's roadmap and support, and the need to fit your process into the app's model, which is flexible but not infinitely so. Raley Procurement carries Atlassian's Cloud Fortified mark on its listing; check the current version and reviews there before you decide.

A decision framework

A rough way to choose:

The single most useful reframe is total cost of ownership, not upfront cost. A DIY build looks free because the license line is zero, but the real bill is the engineering to build it plus years of maintenance as finance changes thresholds, Atlassian ships updates, and edge cases pile up. An app converts that unpredictable internal cost into a predictable subscription. Whether that is a good trade depends entirely on how complex your procurement is and how much Jira admin capacity you can spare.

Bottom line

JSM is an excellent foundation for procurement either way. That is not the question. The question is how much of the procurement layer you want to own. If your process is simple, build it natively and do not pay for an app you do not need. If you are staring down multi-tier approval matrices, multi-line request forms, supplier and product registers, and edit-after-lock auditing, recognize that "just build it in Jira" is a real product commitment, and that is precisely the work Raley is designed to take off your plate.

The practical takeaway: sketch your approval matrix and your purchase request form on one page. If you can build them with native request types, a workflow, and a single automation rule, do that. If the sketch already needs footnotes, you have your answer.

Try Raley Procurement free on the Atlassian Marketplace or see how it works.

FAQ

Does Jira have a procurement template?
Yes. Atlassian's Procurement template is a business project template for Jira with a board, list, form, workflow, and automation, aimed at finance teams tracking purchases as tasks. It does not include order lines, budgets, suppliers, or approval logic; you build those yourself or add an app.

Does Jira Service Management have a procurement template?
No dedicated one. JSM provides the building blocks (portal, request types, forms, approval steps, Assets, automation) and you assemble a procurement process from them, or install an app such as Raley Procurement that uses those blocks.

Can JSM handle multi-line purchase requests natively?
Not as repeatable rows on a portal form. The native options are one set of fields per line, sub-tasks per line, or a Marketplace grid app. Raley Procurement adds order lines inside a single work item.

Do I need JSM Premium to build procurement with Assets?
Not any more. Since February 2026 Assets is included in Service Collection Standard with a 5,000-object allowance; larger allowances come with Premium and Enterprise.

Does Raley Procurement replace Jira Service Management?
No. It runs on top of JSM. Requesters use the JSM portal, the request is a JSM work item with your own workflow, and Raley adds order lines, catalog, suppliers, budgets, approval routing, PDF purchase orders, and goods receipt.

Related reading

• Why intake-to-procure belongs in Jira Service Management
• Jira vs JSM for procurement intake
• Procurement in Jira: 8 lessons from five years in the field
• What is cloud-based procurement software?
• How a growing software team brought purchase approvals into Jira