Does giving an owner every button create a useful screen? Reviewing company status and approving an individual order can be different responsibilities.
I used the new approval model to examine that distinction. In this teaching policy, owners read status while authorized coordinators receive the pending review inbox.
A status figure is not automatically someone’s task
Sales and receivables describe scale and status. Pending approvals identify a next action and the person allowed to take it. Similar card shapes do not make their sources or definitions identical. I did not label every pending count as work for the owner, because permission to read does not establish responsibility to approve.
The existing public role selector changes menu explanations without an ERP permission server. The new local lab derives an inbox from an explicit policy. Combining those explanations must not become a claim of an operational ERP deployment. Interface simplification and enforcement of an allowed action remain separate questions.
Return a coordinator’s actual review targets
inbox reads pending rounds within the coordinator’s company and excludes requests submitted by that same person. Since the policy rejects self-approval, the inbox should not offer those requests as approvable work. Coordinators can inspect another requester’s target. Owners and staff do not receive this approval inbox.
This is not the only appropriate organization model. A company whose owner is the final approver needs an explicit extension and tests. The important choice is to define responsibility rather than grant every operation based on a title. Deriving available work and actions from the same policy improves both explanation and verification.
The list may be stale when the action is pressed
A requester can edit quantity while someone leaves an inbox open. The operation must check whether the listed item remains approvable now. The lab’s approve command compares document state, current content revision and the latest pending target. An old list is not authority to approve newly changed content.
A connected interface should refresh the outcome and provide a way to compare changes. The module reproduces the server-side decision in a local database; it does not implement a browser inbox refresh or real notifications. Showing a readable list and ensuring that only the current target can be acted on require separate checks.
Scope the query and the meaning of the count
Another company’s approvals must be excluded in the database query, not merely hidden by a visual filter. The lab checks actor role and company; staff document reads also remain limited to their assignments. Even a simple response needs a trusted principal. Accepting the synthetic Actor directly from an external request is not authentication.
The experiment does not benchmark a full company reporting service. Production policy still needs to define delegated work, expired targets, absence and multiple review rounds. A mathematically correct total can still describe the wrong person’s workload. Put the meaning of the count close to an owner’s overview instead of asking the title of the panel to explain it.
Let the overview lead into the evidence
The recorded inbox scenario shows one coordinator item and no owner approval items for the same document. It does not mean the owner cannot review anything. Owners can read company document status, while approval remains unavailable. An independent test checks both the allowed read and denied action.
A real screen should connect its count to the target and change evidence, then reflect the current result after processing. This round checks local synthetic records and code, not rendered-browser usability. I share it as a way to simplify what an owner reads without silently expanding the authority behind the view.