APPROVALS / EXAMPLE APP
Purchase Desk.
Turn requests into decisions.
A clear queue for equipment and software requests, with a budget, an owner and a recorded decision.
Sign in → choose workspace → create and deploy your copy.
Give procurement a decision-ready request
Purchase Desk suits employees requesting equipment or software, department managers checking the purpose and procurement colleagues preparing the next step. The supplied records cover monitors, survey software, a meeting-room purchase waiting for another quote and approved support headsets. Together they make it easy to discuss the information a buyer needs before placing an order.
A request contains its title, accountable owner, request value in USD, decision note and status. The queue can be searched by request name or owner and filtered by its review outcome. Summary counts show what is awaiting attention, approved or returned for changes. The editor keeps a short activity list so the next person can see the notes associated with the simulated decisions.
Try the missing-quote conversation
Open the meeting-room item and read why a second supplier quote was requested. Update the note with the information a reviewer would need, save it for review and reopen the item. Approve it only after you are satisfied with the explanation. You can also create a fresh software request and test whether its purpose is understandable to someone outside the requesting department.
All people and records are fictional. Decisions in the browser preview are simulated and changes remain in local storage. Approval does not generate a purchase order, reserve budget or contact a supplier. Resetting the example restores the original requests. A team implementation needs durable records and server-side checks before it can serve as a procurement decision system.
Plan budget and supplier data separately
For an adaptation, a reviewed finance dataset might provide cost centres or remaining departmental budgets. A procurement API could supply supplier references after its endpoints have been approved for the application. Start with a read-only request summary and define the scope of any later write separately. Do not give the generated front end a finance-system password to look up a budget.
Ask the budget owner to specify spending thresholds, substitute reviewers and what happens when a request changes after approval. Those are business approval rules to implement in the app. SpringRoll's release approval determines whether the app version may ship; it does not decide whether an employee may buy a monitor. Verify both boundaries with realistic roles and fictional request amounts.
Adapt the purchasing workflow with Claude Code
Download the source and use these prompts to define the next iteration. Each change adds behaviour beyond the browser starter, so include tests for the requesting employee and the authorized reviewer.
- Add a cost-centre field and supplier quote reference to purchase requests. Require the reference above our configured threshold and explain missing information beside the request.
- Store requests in a shared service with immutable decision history. Prevent employees from assigning themselves a budget-owner approval they do not hold.
- Build a read-only budget lookup using an approved SpringRoll data product, and keep the approval screen usable when the lookup is denied or unavailable.
Take the next step
Take one equipment request through review before deciding which procurement system should receive the approved result.