Decision inbox
The Decision inbox (/decisions) shows staff decisions that need their attention. It is a staff portal area, not part of the client Extranet. A row leads to the decision subject; the inbox does not replace checking the entitlement, operation, or effective access.
Where to find it
The work menu calls the area Waiting for you. When a ready result has rows, a Waiting for your decision band appears above the workspace with a count and a note that the list is incomplete. On a phone the band stays visible in the work area, while the menu item is reached by expanding the top bar and menu.
Open the inbox from the band or menu item. The first read shows a loading state; the band does not appear before the result is read and does not claim that there are no decisions.
What a row shows
The inbox currently includes only manual entitlement adjustments. A row may show the decision kind, entitlement name, client, period, requester, and request time. Names and dates follow the selected locale; technical identifiers are not row content.
Open entitlement takes you to the entitlement card. The inbox does not receive the adjustment amount, reason, or a proposed command, so it intentionally has no Approve or Reject buttons. Decide only after checking the full card and effective permissions.
Incomplete coverage and an empty result
The server reports that inbox coverage is incomplete: other decision kinds do not reach this screen yet. The caveat appears with rows and on an empty screen. Therefore Nothing here does not mean nobody is waiting for you; it is only the result of the currently limited source.
When there is another page, Show more and the number already loaded appear below the rows. The button appends a page rather than replacing rows. When there is no next page, the portal does not invent a total count.
For acceptance, go to Operations → Acceptance; it is not part of this inbox yet.
Loading, error, and retry
While the list is read, the portal shows a skeleton. On failure it says that the list could not be read and offers Retry. Retry reads the list again; it does not approve, reject, or change a decision.
If the error remains, check the session, portal access, and permission to the linked card, then give the reason to an administrator. Do not refresh forever or create a second operation manually: the inbox is read-only navigation to the source object.
When the entitlement is unavailable
A row can load while its linked entitlement cannot be read. The portal then says The entitlement could not be read and hides the navigation button. This is an access or data boundary, not proof that the entitlement was deleted.
Do not copy a technical decisionRef, paste an ID into another route, or work around the boundary through another module. Ask the process owner to check the client context, service access, and record freshness.
Mobile and safe demonstrations
On a narrow screen the incomplete-list note wraps as a whole and the action stays available; entitlement and client names may be visually shortened but are not replaced by machine IDs. Before publishing, check lang/dir, date format, and the absence of money, email, tokens, and real customer data.
Use synthetic entitlements, clients, and requesters for demonstrations. A screenshot must state which source and state it proves: ready rows, incomplete coverage, empty result, retryable error, unavailable entitlement, or mobile composition.