Decisions in the client portal
Extranet decisions appear only in the company or personal context they belong to. The screen explains the subject, available actions, and permission boundary; it does not expose technical identifiers or replace a check of the actual status.
Finding a decision
The portal may show a Waiting for your decision band above the workspace. It lists detected acceptance cases and selected package-usage confirmations; it disappears when none are found. This is a limited overview, so its absence does not prove that no other response is waiting.
If the list read fails, the band stays visible with a human-readable Could not check message and Retry. This is a read failure, not an empty result; Retry reads again only, so do not submit an accept, reject, or dispute response again. The separate cross-context usage scan can still fail without its own warning; a missing confirmation is not proof that no confirmation is pending.
The band is not a live feed: a new decision may appear only after the next read or a page refresh. If the client has more than one company, a usage confirmation may be found in another available context; opening it switches to the required context. Check the company name before acting and wait for the reread to finish.
Acceptance opens at /extranet/decisions/work/<acceptanceCaseId>, an offer at /extranet/decisions/offer/<quotationId>, and a usage confirmation at /extranet/decisions/usage/<entitlementId>/<usageRecordId>. Offers do not have a separate list in the client portal.
Accepting delivered work
The acceptance card shows a work title when it can be matched unambiguously to a delivery, the delivery date, and a What was done section. When the server does not expose the work volume, the portal does not invent a quantity or draw response buttons. An accepted, returned, or not-yet-open case shows an explanation instead of another action.
When the work is awaiting your response, you have the right, and sign-in confirmation is enabled, the card may show Accept, Send back, and Reject. Sending work back or rejecting it requires a written reason. Acceptance starts the follow-up billing flow; sending back and rejecting have different consequences.
Read the confirmation text before sending. Accept means an invoice will be raised for the accepted work and acceptance cannot be undone. Send back sends the work for correction and does not invoice it now. Reject rejects the work in full, does not invoice it, and cannot be undone. None of these actions proves payment or that a final invoice was issued: check the current billing documents and context after reloading the status.
Work details and recovery
Work details can be loading, empty, temporarily unavailable, or disabled for the current profile. “The detailed breakdown is not published here” is not the same as a read failure, and an empty list is not proof that the work contains nothing. If the case belongs to another client context, the portal switches context and reloads it.
If the context becomes stale during a read, the pending-decisions strip and card may temporarily disappear while the portal synchronizes the selected company. This is a bounded recovery state, not proof that the decision is absent: wait for synchronization or switch context, then reload the screen. Do not submit the response again before recovery finishes.
For loading, missing, or read-error states, use Back or Try again after checking the context. Do not expose an acceptanceCaseId or technical error code, and do not repeat a response until you know whether the status changed.
Commercial offers
An offer opens only from a direct link. Its card can show a validity date, line items, quantities, and amounts; a total appears only when all lines use one currency and one scale. Money screens require an explicit expected-versus-observed currency check in the page locale.
Accept and Decline appear only when the server says the decision is open. Each opens its own confirmation before sending: accepting places the order on these terms and starts work, and cannot be changed; declining records that the offer did not suit and starts another offer, and cannot be returned to. An accepted or declined offer cannot be answered again. No permission, missing MFA, a closed status, and an expired offer are different states, not one generic error.
Confirming package usage
/extranet/decisions/usage/<entitlementId>/<usageRecordId> shows usage that has already been recorded, with its quantity, unit, and time. When the linked entitlement is available, the panel may also show the service or package context, client context, period, granted amount, and remaining balance; unavailable fields are omitted rather than replaced by technical IDs. Your answer is a receipt of agreement or dispute: it does not reverse the usage, change the balance, or replace a separate staff correction.
Looks right sends the response with one click. Dispute opens a required reason field. If the record is not open for your confirmation, it may need no answer, already have one, or no longer be available; this state offers neither response buttons nor Try again. Try again is only for a read error.
When a response is unavailable
No permission, MFA setup, an already recorded answer, a closed mode, and a temporary read error lead to different next steps. Check the current context and permissions first, then use Try again only for a read. Do not treat an empty card as missing data or a success toast as proof until the state has been reloaded.
Mobile and privacy
On a narrow screen, actions and explanations must wrap without horizontal scrolling; dates, units, and amounts stay in the page language. Use synthetic work names, line items, and dates for demonstrations. Never publish real client names, links, case identifiers, payment data, or another person's portal; Arabic captures also require RTL review.