Shared Product Blueprint

Purchase Request Approval

A read-only Product Blueprint created with IdeaMade.

Purchase request approval app

Purchase Request Approval

A small internal web app for a 10-person studio or nonprofit where staff submit purchase requests with item, amount, and reason; approvers review and approve or reject pending requests; and an admin manages who is a Requester or Approver. Requesters see only their own requests and can withdraw pending ones. Rejections require a written reason, amounts are locked after submission, and every status change is recorded in immutable history.

Users and roles

The people who interact with the product.

Requester

Any staff member who submits purchase requests and tracks their own requests.

  • Submit a purchase request with item, amount, and reason
  • See the status of only their own requests
  • Withdraw a request that is still pending

Approver

A staff member responsible for reviewing pending purchase requests and approving or rejecting them.

  • See all pending requests
  • Approve or reject pending requests
  • Record a written reason when rejecting

Admin

An Approver who also manages which signed-in people are Requesters or Approvers.

  • Assign signed-in people to the Requester or Approver role
  • Review and decide on purchase requests like any Approver

Key workflows

The main paths users take to reach an outcome.

Sign in to the appRequesterCore
1

Sign inEnter credentials on the Sign in page. There is no self sign-up; an Admin assigns roles to signed-in people.

Outcome: The staff member is signed in and their assigned Requester or Approver role is applied.
Submit a purchase requestRequesterCore
1

Open My requestsSee your own requests with status; when there are none yet, start your first request.

2

Create a new requestEnter the item, amount, and reason, then submit. The amount is locked after submission.

3

Review the submitted requestOpen the request detail to see all fields, status, and the full history of actions with who and when.

Outcome: A pending purchase request exists with item, amount, and reason, and a Submitted history entry records who and when.
Withdraw a pending requestRequesterCore
1

Find your pending requestOpen My requests and select the pending request.

2

Withdraw the requestWithdraw the pending request from its detail page. To change the amount, submit a new request afterwards.

Outcome: The request status becomes Withdrawn and a Withdrawn history entry records who and when.
Approve or reject a pending requestApproverCore
1

Open Pending approvalsSee all pending purchase requests; when nothing is pending, confirm there is nothing awaiting a decision.

2

Review the requestOpen the request detail to see all fields, status, and the full history of actions with who and when.

3

Approve or rejectApprove, or reject with a written reason. You can never approve or reject your own request.

Outcome: The request status becomes Approved or Rejected, with a written reason on rejection, and an immutable history entry records who and when.
Manage user rolesAdminCore
1

Open Manage rolesSee signed-in people and their assigned roles.

2

Assign a roleAssign the person the Requester or Approver role. There is no self sign-up or invitation flow.

Outcome: The person has an assigned Requester or Approver role.

Pages

6 pages in the MVP

Sign inLet staff sign in so their assigned Requester or Approver role can be applied. There is no self sign-up or invitation flow; an Admin assigns roles to signed-in people.
Public
Sign in
My requestsShow the signed-in requester's own purchase requests with status, and provide the entry point to create a new request. When there are no requests yet, invite the requester to create their first one.
Signed in
My requests
ItemAmountReasonRequester
New requestLet a requester submit a purchase request with item, amount, and reason. The amount is locked after submission; to change it the requester withdraws and submits a new request.
Signed in
New request
Pending approvalsShow approvers all pending purchase requests so they can open and decide on them. When nothing is pending, confirm that there is nothing awaiting a decision.
Signed in
Pending approvals
ItemAmountReasonRequester
Request detailShow all fields, status, and the full history of actions with who and when, and provide the actions available to the viewer: withdraw a pending own request, or approve or reject a pending request as an approver. Rejecting requires a written reason, and a person can never approve or reject their own request.
Signed in
Request detail
Manage rolesLet an Admin assign signed-in people to the Requester or Approver role. There is no self sign-up or invitation flow.
Signed in
Manage roles

Product decisions

Choices you can confirm directly in the Blueprint.

Who can see the decision reason recorded when a request is approved or rejected?ConfirmedWho can see the decision reason recorded when a request is approved or rejected?
Requester sees rejection reason; approvals need no reason

Assumptions

Items that should be verified before implementation.

The requester sees the rejection reason on their own request; approvals need no reason. Decision reasons are visible to approvers.

Medium impactAccepted

Each signed-in person holds exactly one role at a time: Requester or Approver. Admins are Approvers who also manage roles.

Medium impactNeeds confirmation

The Resubmitted history action is recorded when a requester submits a new request after withdrawing a previous one; the new request is a separate record and the withdrawn request keeps its own history.

Low impactNeeds confirmation

Sign-in relies on an existing authentication provider to supply staff identity; the app does not create accounts or send invitations.

Medium impactNeeds confirmation