Review purchase requests

This example helps an operations team review purchase requests without hiding the policy decision or bypassing human approval.

Outcome

For each request, the team needs to know:

whether required information is complete;
which policy threshold applies;
whether quotes or security review are required;
who must approve the request;
why the request is ready, blocked, or exceptional.

Add the business context

Create a Procurement Operations Project and add:

purchasing, security, and approval policies as Sources;
reviewed Knowledge pages for thresholds and exceptions;
a Purchase Requests table;
a Suppliers table when supplier status changes frequently.

Purchase Requests can include requester, department, supplier, description, amount, currency, requested date, cost center, risk category, status, required approver, and exception reason.

Prompt to try

Attach one request and the relevant Knowledge pages:

Review this purchase request against our purchasing and security policies.

Return:
- the information supplied;
- missing required fields;
- the applicable amount threshold;
- required quotes, reviews, and approvers;
- policy citations for every requirement;
- a status of ready for approval, incomplete, or exception;
- the exact next action.

Do not approve the request and do not contact the supplier.

Review the result

Check amounts, currencies, thresholds, supplier identity, and policy effective dates. Confirm that Cromo distinguishes between:

a complete request;
a request that satisfies policy;
a request that has actually been approved.

These are separate states.

Build a Process Skill

Create Review a purchase request from the approved Knowledge page. Include standard requirements, threshold branches, exception handling, and the expected review output.

Automate preparation

Create a workflow named Prepare purchase request review.

When a new Purchase Request record is created:
1. validate required fields;
2. apply the Review a purchase request process;
3. write the review status, required approver, and next action to the record;
4. create a review summary file;
5. flag exceptions and high-risk suppliers for human review.

The workflow must never mark a request as approved.

Run test cases immediately below, exactly at, and above each policy threshold.

Dashboard example

Create a Dashboard showing:

requests awaiting information;
requests ready for approval;
exceptions by reason;
total requested value by department;
requests without a required approver;
age of unresolved requests.

Expected result

State	Meaning
Incomplete	Required information is missing
Ready for approval	Policy review is complete; a person must decide
Exception	A policy rule needs explicit human handling
Approved	Set only after the authorized approval occurs
Rejected	Set only with a recorded decision and reason

Safety checks

Preserve the policy citations used for the review.
Do not turn a recommendation into an approval.
Test boundary values and multiple currencies.
Restrict supplier-facing connector actions until separately approved.

Getting Started

Concepts

Guides

Examples

Reference

Review purchase requests

Outcome

Add the business context

Prompt to try

Review the result

Build a Process Skill

Automate preparation

Dashboard example

Expected result

Safety checks

​Outcome

​Add the business context

​Prompt to try

​Review the result

​Build a Process Skill

​Automate preparation

​Dashboard example

​Expected result

​Safety checks

Outcome

Add the business context

Prompt to try

Review the result

Build a Process Skill

Automate preparation

Dashboard example

Expected result

Safety checks