Home Eduka Suite Case Studies Community Forum About Us
Request a demo
0
Upvotes

Multiple Referrals: Proposal to Improve the Interface to Prevent Multiple Submissions CommunicationMessenger


by C. V. User
Friday, 20 March 2026 at 08:17  
405 views   1 replies
Hello,

Would it be possible to implement protection to prevent unintentional duplicate sends?

During a recent send operation, in a context of high load and stress, the same message was sent multiple times. Because the operator did not see the confirmation message (pop-up) indicating the end of the send, he referred to the displayed status.
However, the current labels — notably "Message partially sent" and "Click here to continue sending" (below) — can suggest that the send is blocked or interrupted, and that action is required to restart it. In reality, the send may still be processing on the system side, which creates ambiguity.
Furthermore, the "Resend to…" option found further down offers notably "Resume recipients of failed sends", which creates a new distinct send, and this can easily generate duplicates if the user thinks they are restarting the same job.

In this context, a new send was triggered a few minutes later, while the first was still executing (but more slowly), which resulted in multiple parallel sends for the same message.

To limit this risk, several improvement options could be considered:

  1. Clarify status messages to explicitly distinguish an ongoing send from a truly interrupted send

  2. Add a more explicit intermediate confirmation (e.g.: "send in progress – are you sure you want to restart?", "This action will create a new send for the failed recipients. Do you want to continue?" ...)

  3. Implement a temporary locking mechanism preventing the triggering of a new send as long as the previous one is not complete


On our side, we are revising the wording of the orange banner to remove any ambiguity, but we have doubts about the technical probability of an incident:

Scenario 1 – The "continue send" action is still sometimes necessary (Send genuinely blocked)
The link is explicit: it does not encourage clicking by default. The user understands that they should only act in the event of a genuine blockage.
Ex. "Send in progress (941/1253). The send is continuing automatically. If progress remains stuck for several minutes, you can force resumption [Resume send if necessary]"

Scenario 2 – The "continue send" action is hardly ever necessary (Send is always active)
The banner becomes purely informational. If a problem occurs, another message or a specific notification appears.
Ex. "Send in progress (941/1253). No action required. The send will complete automatically." (No link)


1773979839689-image.png.jpg

1773994512798-image.png.jpg
  Thread replies(1)
C. V.User
Friday 20/03/2026 09:02 📨

Il faudrait dissocier clairement :

  1. Statut technique : en cours / terminé / échoué

  2. Action utilisateur attendue : aucune / requise

0
Communication Home

Join the Eduka community

The Eduka community is where the schools using Eduka Suite talk to one another. It is the place to discover what is new on the platform, share advice and good practice, ask questions and suggest the improvements you would like to see. Every thread is read by the Eduka Software teams, and the suggestions that bring the most schools together feed the product roadmap. Anyone can read the forum, taking part requires an Eduka customer account.

Is your school already an Eduka customer? Sign in to your customer account to start a thread and reply to other schools.

Go to my customer account

Not using Eduka Suite yet? Request a demonstration and discover the platform with our team.

Request a demo