> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gocromo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Review purchase requests

> Apply purchasing policy consistently and route exceptions for human approval.

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:

```text theme={null}
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

```text theme={null}
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.
