Skip to main content

Approvers

Approvers make workflow decisions. They review a record at a specific point, then approve it or return it for correction.

Approval in Grinea is tied to the record and its current status. It is not a separate workspace where the procurement process is rebuilt. The approver reads the record, checks the decision that is being requested, and acts from the available approval controls.

Approval actionsApproval actionsApproval FlowApproval FlowReviewer noteNext approverReason required on returnApproveReturn
Approval work is handled from record headers and confirmation modals, not from a separate flow screen.

Basic Concepts

Approval gates protect the handoff between planning, buying, sourcing, and ordering. A record moves forward only when the required decision has been made.

An approval action should answer the question for that gate. A PR approval confirms that the request can move toward sourcing. A supplier selection approval confirms that the selected supplier can move toward PO creation.

Approval Work

Status-driven actionsStatus-driven actionsApprovedDetailsApproval FlowDeliveryRecord detailAction stateCurrent ownerNext actionLast updateCreate RFQReturnCancel
Actions appear in the page header or alerts only when the record status allows them.

The app exposes approval actions when the record status, current owner, and user's role match the workflow. If an approval button is missing, first check the status and assigned user before assuming the page is broken.

Approvers should use the record tabs to inspect the decision context. For PRs, that usually means line items, delivery details, documents, and approval history. For supplier selection, it means the recommended supplier, quotation comparison, and justification.

Returning A Record

Submit supplier selectionSubmit supplier selectionSupplier SelectionSupplier SelectionRecommendation overviewSupplier justificationReview and submitBackSubmit Selection
Supplier selection is reviewed in a modal before the recommendation is submitted for approval.

Return a record when the decision cannot be made because something specific needs correction. Use a clear reason so the owner knows what to fix.

Do not use return as a general comment tool. Returning changes the workflow state and hands work back to another user.

Boundaries

Approvers do not own the record after approval unless they also have another role in the workflow. They should not change supplier handling, delivery receiving, or PR construction unless the page explicitly gives them that action.

Their role is to make the required decision at the required gate and leave a useful reason when the record cannot move forward.