Designing a Budget Visibility Feature for B2B Approval Workflows

The Problem

I work on a B2B e-commerce platform where certain enterprise clients use a budget approval workflow. Requesters place orders, and designated approvers in the approval chain sign off on them.

The ops team raised a pain point: approvers had no way to see how much budget their requesters actually had left. They were approving orders blind — no visibility into remaining balances, no way to gauge whether a request was reasonable relative to available funds.

What Was Requested vs. What Was Built

The original request had two parts:

1. Let approvers view requesters' budget status
2. Let approvers share and use requesters' budgets to place orders themselves

I rejected the second request during planning. The platform's budget model assigns budgets to individual users, not departments. Implementing shared budgets would have meant redesigning the entire budget management system — a fundamentally different scope from adding a view page.

Mobile screens were also designed but descoped to "later" during the feedback cycle. The design assets were preserved, but development focused on desktop only.

One more constraint: someone suggested embedding requester budget info into the existing approval history page. That didn't work either — the approval history page is shared across all client types, not just budget-approval clients.

Permission Design

The core question was: who gets to see whose budget?

The rule ended up simple. A logged-in user can only view budgets of requesters in approval chains where they serve as a 1st, 2nd, or 3rd-level approver. When the approval chain changes, visible requesters update immediately.

One edge case needed handling: when a requester includes themselves in their own approval chain, their own budget shouldn't appear in this new view. They can already see it in the existing budget page.

Feature visibility is controlled by a system-wide configuration code. Only clients registered under a specific code see the menu at all. Everyone else never knows it exists.

Screen Design

Three screens on desktop:

The menu screen adds a "View Approval Targets" item under the existing Budget/Approval menu — visible only to budget-approval clients.

The list screen shows a filterable table of requesters in the approver's chain: name, ID, department, and total available budget at a glance.

The detail screen displays a selected requester's full budget breakdown. Rather than building this from scratch, it reuses the existing personal budget page with the requester's data injected. Same components, same layout, different data source.

Bugs Found After Deployment

Two issues surfaced during verification.

First, the member name displayed the logged-in approver's name instead of the requester's. The page was pulling the session user's info rather than the selected requester's.

Second, the "Previous Page" button navigated to the wrong destination — it should return to the requester list but didn't.

Both were fixed and redeployed.

Takeaways

Scope control was the most important decision. Had I accepted the "shared budget" request, we'd have been redesigning the budget system itself. Identifying the boundary between "feasible enhancement" and "architectural change" saved the project.

Reusing existing UI components kept the effort manageable and gave approvers a familiar interface. No learning curve — they already knew how the budget page worked.

Leveraging existing data structures for authorization was the cleanest approach. The approval chain data already encoded "who supervises whom." No separate permission table was needed — the relationship data doubled as the access control rule.