The procurement process begins by answering a few questions: What are we buying, for what purpose, and with what budget? When answers are scattered across email, Excel, and messaging apps, it’s easy to get confused and lose control of the process. Approvals get lost in threads, the budget is checked too late, and the IT or security departments only find out about the purchase after the software is already up and running.
The purchase requisition app streamlines the pre-purchase process. It collects the necessary data, forwards the request to the appropriate people, monitors its status, and maintains a history of decisions.
What exactly does a system like this do?
The purchase requisition system is a business application that guides the user from submitting a request to making a decision: approval, rejection, or returning the request for additional information.
It does not necessarily have to replace an ERP system right away; rather, in many organizations, it functions more effectively as an operational layer between business, finance, procurement, and IT.
Above all, it should ensure:
- request form,
- automatic acceptance rules,
- notifications for decision-makers,
- history of decisions and comments,
- support for attachments,
- status visible to the applicant,
- reports for finance, procurement, and IT,
- integration with ERP, email, Teams, or Microsoft 365.
As a result, less time is spent searching for information and clarifying statuses, and more decisions can be made based on complete data.
Where does the purchasing process most often get stuck?
The problem usually arises before the actual purchase—most often when submitting the application.
An employee requests: „I need a license for the XYZ tool.” Without specifying the cost, justification, budget owner, supplier information, data access, or validity period. In response, an email is sent back with questions. In addition, another person joins the conversation. A few days later, it’s hard to determine who’s making the decision—or whether one has even been made at all.
In the short term, Excel may be sufficient, but on a larger scale, it starts to become a hindrance: it doesn't enforce rules, doesn't ensure data completeness, doesn't keep a complete record of the decision-making history, and doesn't clearly indicate who is currently handling the request.
From Request to Approval: What a Well-Structured Process Looks Like
A well-designed process doesn't have to be complicated at all.
- An employee submits a purchase request.
- The system verifies that the data is complete.
- The request is submitted for approval in accordance with the rules—for example, based on amount, category, project, or supplier type.
- The approver receives a notification in Teams or via email. If the approver is unavailable, the substitution mechanism forwards the request to a previously designated person. This ensures that the process doesn’t come to a halt just because someone is on vacation or sick.
- If any information is missing, the requester and approver clarify it within the system, without maintaining a separate email thread.
- An application may be approved, rejected, or returned for further information.
- The system records the decision, comments, and dates.
- Once approved, the request is assigned a PO (Purchase Order) number and is forwarded to Purchasing, Finance, the ERP system, or the next process.
With a workflow organized in this way, business rules guide the application’s path, and all decisions made are recorded in the process history.
What should the application form include so that no one has to ask for additional information?
A form must strike a balance between completeness and convenience. If it’s too short, it raises questions from those reviewing it. On the other hand, if it’s overly elaborate, it encourages users to bypass the process.
To start with, it's a good idea to collect:
- the name and description of the need,
- purchase category,
- estimated cost and currency, including support for multiple currencies for international purchases,
- cost center or project,
- the budget owner,
- the preferred supplier, if one has already been selected,
- business case,
- the date by which the purchase is needed,
- Attachments: proposal, specifications, contract, or quote,
- information regarding a vendor's access to data, systems, or users,
- information on whether the cost is a one-time expense or a recurring expense.
The order-filling process is significantly accelerated through integration with internal databases—for example, the ability to select order items from a catalog of available items of a given type, rather than entering them manually.
The last item on the list is easy to overlook. Subscriptions, SaaS licenses, and recurring services should be visible as early as the purchasing decision stage, not just when the invoice arrives.
Acceptance rules: simple to start with, ready for expansion
There’s no need to start with a complex matrix containing dozens of exceptions. A better starting point is a few rules that reflect how the company actually makes decisions.
The approval process can be contingent on, among other things:
- purchase price,
- categories,
- organizational unit,
- cost center,
- project,
- supplier type,
- whether the purchase is standard or non-standard,
- access to data or the IT environment,
- the nature of the cost—one-time or recurring.
A simple purchase may require a single decision. For higher-value or higher-risk purchases, other departments—such as finance, IT, security, the legal department, or the process owner—may be involved in the process.
Ongoing budget monitoring is also a key element. The system can compare the amount of a request with the limit assigned to a given category and notify the requester or approver when the threshold is approaching. This allows the CFO to identify potential overspending before invoices are posted, rather than after the fact.
The rules should be clear to users, and the person submitting the application must be able to see what stage it is at and who is currently making the decision. This reduces the number of emails asking, „What’s happening with my application?”.
Automation in a Microsoft Environment
In Microsoft-first organizations, the natural choice is to combine Power Apps, Power Automate, Dataverse, Microsoft Teams, Outlook, and Power BI.
Each of these system components can be responsible for a different part of the process. Power Apps provides the form and user views, Power Automate handles the approval workflow, and Dataverse stores the data and history. Teams and Outlook, in turn, serve as notification channels, and Power BI can display the request queue, statuses, categories, and process workload.
Microsoft Power Automate supports various approval options, including sequential approval, approval by all required parties, and the „first response” option. This allows you to handle both simple requests and multi-step decision paths.
Make an appointment for a 30 min consultation
Bring us your current workflow description and a few sample requests—we'll see if we can quickly migrate your purchasing process to Power Apps and Power Automate.
Security
A purchase requisition system processes financial data, information about suppliers and users, and sometimes details regarding IT infrastructure. Therefore, it should not be created as a „quick-and-dirty form.”.
The project must absolutely take into account roles and permissions, access only to relevant records, change history, attachment control, and restrictions regarding connectors and integrations. A separate issue is the separation of the test and production environments and clearly defining who has the authority to modify acceptance rules.
Within the Power Platform, you can use the Dataverse role model, data policies, and auditing for this purpose. This is particularly important when purchasing SaaS tools, IT services, and systems that provide vendors with access to company data.
Integrations: ERP, Finance, Purchasing, and IT
The demand management system does not have to automatically generate orders in the ERP system from the start, but it should be designed in such a way that subsequent integration does not require a complete overhaul of the application.
It is most often associated with:
- an ERP system or a financial and accounting system,
- supplier database,
- contract processing,
- license and subscription registry,
- an IT ticketing system,
- a catalog of services,
- budget reporting.
It is particularly useful to link requests to the cost invoice workflow. If an approved request has a PO number and that same number appears later on the invoice, settlement and posting can occur automatically without the need for manual document matching.
It is important to separate the purchasing decision from the subsequent ordering process. First, the organization approves the need, budget, and risk. Only then are the next steps initiated: the order, contract, invoice, or provisioning.
Reporting and Audit Trail
Without reporting, even a well-designed and well-configured system can quickly become nothing more than a convenient form. Meanwhile, added value also emerges at the level of managing the entire process.
Information on the number of pending requests, their statuses, and the waiting time for a decision is particularly valuable. The finance and procurement departments can analyze costs by category and cost center, requests that have been rejected or returned for revision, recurring costs, and suppliers requiring further evaluation.
Equally important is the audit trail, which should clearly answer the following questions: Who submitted the request? Who approved it? When was the decision made? What information was used as the basis for the decision? And what changes occurred during the process?.
How to Get Started Without Dragging Out the Project
A good place to start is with a limited and clear scope. To begin with, you can streamline the request and approval process itself.
A Practical Path
- Describe the current process: who submits the request, who approves it, and where exceptions occur.
- Select various types of purchases to get started, such as licenses, hardware, and IT services.
- Specify the minimum data required on the form.
- Create an acceptance matrix.
- Define the following roles: requester, approver, finance, purchasing, IT, and security.
- Prepare status views and reports.
- Launch a pilot program in one or two units.
- Wait until after the pilot phase to expand the rules and integrations.
What We Need to Get Started
To start with, examples of current requests, a description of the current approval process, a list of purchase categories, and basic decision thresholds are usually sufficient. It is also essential to provide information about the systems with which the application is to integrate, as well as the individuals responsible for approving the requirements.
This set of information makes it possible to move from discussion to creating a process prototype without first designing the entire target system.
When is it a good idea to build a custom application?
Not every purchasing process requires a dedicated application. If there are only a few requests, a single person makes the decision, and the risk is low, a simple form may be sufficient.
A business application becomes increasingly important when requests pass through several departments and decisions depend on the amount, category, or available budget. The same applies to the control of IT and SaaS purchases, recurring costs, audit requirements, or a large number of user inquiries about status.
A dedicated app also makes sense when the process is intended to run directly within the Microsoft 365 environment rather than in yet another separate tool.
In this case, the purchase requisition system is no longer just an add-on to the process; it becomes a mechanism through which the organization controls spending even before it is incurred.
Submit a sample purchase request
We'll show you what it would look like in a working system with an automated approval workflow and a status view for the applicant.
Frequently Asked Questions (FAQ)
Not always. It’s often better to start with an application that handles requests, approvals, and status updates, and only later integrate it with the ERP system. The ERP system itself can still handle orders, bookkeeping, and billing.
Yes. In many companies, it can be built using Power Apps, Power Automate, Dataverse, Teams, Outlook, and Power BI. The most important thing is to properly design the data, roles, approval rules, and governance.
It depends on the purchase amount, the purchase category, and the level of risk. The process typically involves the budget owner, a supervisor, and representatives from finance, procurement, IT, security, or the legal department.
The form should include information about data access, integrations, user accounts, data location, and the type of provider. This allows the CISO or IT department to assess the risk before making a purchase.
Just a few of the most important ones will suffice. It’s better to launch a simple process, collect data during the pilot phase, and only then add exceptions based on that data. A matrix that’s too complex at the outset unnecessarily prolongs the project.
Both elements must work together. The form collects the data needed to make a decision, while the workflow ensures that the process runs smoothly. An incomplete form leads to additional questions, and a poorly designed workflow halts the process as soon as the application is submitted.
The process should be accessible where users already work: in Microsoft 365, Teams, Outlook, or a familiar corporate portal. A simple form and a visible request status make it much easier to use the system on a daily basis.
Would you like to see what this cycle looks like in practice?
We'll review your current process, identify the initial scope, and demonstrate a working workflow prototype—from request to approval.
Learn about our other services
Business applications
Services for applications and turnkey solutions in the area of process digitization and modern work environment.
Full support and optimization of IT infrastructure, ensuring stable development of your business.
IT infrastructure
Security of deployment and maintenance of Microsoft 365 and Azure services that enable flexible management and cost optimization.
