I have an app where the user can choose to do multiple actions all at once. This is done by first choosing the actions, putting them in an "outbox" (like a cart in an online shop) and then executing them all at once by pressing the "Send"-button. Most of the time it works fine, but somethimes the whole, or part of the outbox fails. What is the best way to handle this?

  1. Display an error message that lets the user know something went wrong, with the options to Cancel or Try again

  2. Display a message stating what went right and what went wrong and then land the user back in the outbox so the user can make optional changes and try again.

  3. Display a message stating what went right and what went wrong and then land the user on the startpage, with the actions not executed remaining "hidden" in the outbox (an icon with a number on it)

Or maybe a completely different approach?

If some of the actions succeed and some don't, is it best to show two messages (one for what went right and one for what went wrong) or one combined?

Generally we try to use the principles of Material design, but I haven't found a solution for this problem there.

4 Answers 4


In the first place, I think you should handle this in the development.

What is the result of this error? No data is saved or just a part is saved? Anyway, the user may not remember exactly the items and the options 2 and 3 seems confusing.

I think you should display the message where you apologize for the error and let the user decide if try again. You can let just this button if the message is not in a pop-up, without the "cancel" button because he has the menu.

A similar example in the Material design Guidelines - Patterns– Errors

enter image description here is:



About your proposals:

  1. Could be a good solution if either all or none of the actions need to be uploaded. The user will retry until he gives up, and cancels.

  2. If what went wrong depends on the user it could be a step after the former.

  3. If those actions can succeed depending on some change in the input from the user, you could bring him back and let him know what needs to be changed.

  4. (possibly 1b) The user might want to retry the actions that didn't work, so instead of a Retry button for all the sections one per section (the way Google drive upload dialog works, for example).

If you could make the upload for each section independent (either automatically or with an upload button in each section), the user could get extra information while filling, instead of only after submit. For example: user has SectionA, SectionB, SectionC. When he finishes filling SectionA it starts uploading asynchronously (the user is aware of this and knows if it went correctly or if it didn't) and the user can continue filling SectionB meanwhile. Sections that could upload will remain and he can retry to upload again the ones that did not work.


Let the user know the limitations he has before he starts doing anything.

Think of a common form where the user needs to enter a password of a certain length. The system lets the user know the password needs to be of a certain length before he starts typing. If he types less than the minimum and goes to a different input, validation will give him feedback when focusing out of the input, before submitting anything.

I don't think it is necessary to be specially technical about the error message, word the error as understandable as possible. Let the user know if the mistake was from the system or not. And let him try again, now that he knows what didn't go correctly.

  • The problem is that the issues that lead to the error message are always technical. For example; our target users work in an enviroment that can have quite unstable wifi so loss of connection is not uncommon. The error handling would need to adress this type.We already have a validation in the separate actions that the user can see while still in the inbox, the same ways as forms in general, so this is not the issue. Commented Nov 15, 2016 at 13:17
  • Therefore, too, it is never the users "fault". Commented Nov 15, 2016 at 13:19

The most important question is if you are aware what the possible outcomes can be. Do you have a conception of all possible errors? And can these be categorized?

Unless it's a technical issue of your platform, you do want to let the user know (before he submits it to the basket) that the action will not be possible.

If something technical is going wrong, it's hard to explain this to the users. And you probably don't want to. Unless the technical issues that might occur are already known.

Trying again (and again and again) with no solution, will definitely frustrate the user, so I wouldn't recommend that.

So, as you suggest, you could give the option to process the rest of the 'cue'.


I recommend your first option in combination with showing your "outbox" items as a list and visually indicate succeed items and failed items. For examples Succeed ones by green color and failed ones by red. Now you can put buttons as "Retry failed items", "Retry All", "Cancel" or etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.