Ask for explicit client confirmation when an action triggers a choice, transfer or meaningful next step. Do not require confirmation for every small checkbox. An extra click is justified only if it prevents uncertainty and lets clients check what will happen before submitting.
Portals become cumbersome when every action ends with “Are you sure?”. The opposite is equally risky: one tap on a mobile card immediately submits a final choice. Design confirmation around consequences, reversibility and the need for evidence.
Assess consequences and recoverability
Use a confirmation step if any of these apply: an order or price consequence arises, a document is formally submitted, another party starts work, a deadline closes or recovery requires manual intervention. Changing a profile colour or saving a draft usually does not need a second step.
Yindle Portal actions have open, completed and confirmed statuses, with the time and person confirming. Questionnaire submissions also distinguish draft, submitted, reviewed and confirmed. Your organisation determines which transition is truly significant.
Let the summary support the decision
A good confirmation page does more than repeat the button text. Show the subject, file, selected options, any quantities or amounts, attachments and what happens after submission. Mark an unknown price as “to be determined” instead of making it disappear from a total without explanation.
Use one primary button with a specific verb: “Submit final choices” is stronger than “Continue”. Also provide a route back to editing. After submission, show an acknowledgement with a timestamp and an accessible summary.
Worked example: fictional childcare provider
In this fictional example, childcare centre Zonnewijzer asks parents to choose holiday childcare days. Progress is saved automatically without a pop-up. On the last step, parent Ravi sees the selected days, location and authorised people for collection. The button reads “Submit holiday schedule”.
After submission, the status is submitted and Ravi sees that the planner still needs to check it. An employee confirms the place later. The system therefore does not pretend the request has already been accepted.
Use the confirmation threshold
Score each action on three questions, each worth zero to two points:
- Consequence: does nothing change, does internal planning change, or is there an external or binding arrangement?
- Recovery: can clients go back themselves, do they need help, or is recovery barely possible?
- Evidence: is an acknowledgement useful, important or essential for subsequent work?
Zero to two points calls for direct feedback. At three or four points, a summary is often sensible. Five or six points warrants deliberate confirmation with a clear outcome. This is a design aid, not a legal classification.
Test duplicate and interrupted submissions
During acceptance testing, have someone double-click, lose their connection and return using the back button. Clients must not create two requests or be uncertain after an error whether anything was received. Show an in-progress state, make the action idempotent where possible and allow the current status to be retrieved again.
Also describe the route for changes. Can a submitted choice still be amended, by whom and until when? If this must happen outside the portal, point specifically to the right contact route instead of a general mailbox.
A shared file is an important edge case. If two clients have access, decide whether each can submit independently or one acts as the decision-maker. Do not just show the account name; clarify in advance whose confirmation the process accepts. Otherwise, an apparently valid submission can still produce an internal conflict.
Assess accessibility too. A summary must be logical to navigate with a keyboard and screen reader. Do not use a preselected consent checkbox or hide conditions in a download without context. Keep errors beside the relevant section and preserve other entries when one field is missing.
A short decision protocol helps recovery after a mistake: who receives the request, is the original submission retained, which subsequent status does the client see, and which downstream party must receive the change? Write this protocol before the first final submission.
Read the broader implementation guide for a customer portal or explore the capabilities of Yindle Portal. To determine which actions in your process deserve confirmation, review one decision journey with Yindle.