ECA Use Case: Notifications

Welcome to the second edition of ECA use cases. The first one was about Forms in Drupal. And all this got started by the Value proposition of ECA for Drupal CMS. Today, let’s talk about notifications in Drupal, a topic that may be much broader than expected.

I remember a few years ago on a local meetup, somebody made a light joke about Drupal’s maturity, and the fact that it still gets away without shipping a strong notification framework. It’s one of those curiosities. Drupal is made of so many strong APIs, and it ships with amazing implementations for all of them. Think of the Queue API as an example, it’s a nice little framework that lets developers add tasks to queues, and Drupal takes perfect care of processing them safely.

On the other hand, something seemingly essential, like notifications, is still not even thought of. And back then, we’ve had one of those smiling experiences: Drupal covers most of those really fancy topics, but some of the basics just seem to be forgotten. Nobody is perfect, right?

When we elaborate on notifications in a perfectly generic context, we need to consider the “what”, “when”, “who”, and “how”:

• What happened that somebody should be notified about.
• Who needs to be notified.
• When should notification be delivered, each notification individually or a digest of many notifications at a certain time.
• How should the notification be delivered, just inside Drupal or maybe pushed out via email or on other delivery channels.

This article will not explore all 4 of those areas. But for the purpose of describing an important use case, let’s enumerate just the different “What”s, as there are so many, and this should be eye-opening:

• New content got published, either any or just specific content like e.g. from a given author or of a specific type.
• Somebody commented on my content.
• Somebody replied to my comment.
• A new user registered on the site.
• A visitor or a user submitted a form, e.g. a contact form or a request for proposal.
• My user profile was updated, either the password, or a second factor was added, or any other field, that I have to pay extra attention to.
• An error was logged on the site, something system administrators should be aware of to analyse and fix it.
• A long-running process like a batch export was completed.
• A response in a chat arrived when the user is no longer present.
• Content was added to a group that a user is a member of.
• ... and that list can go on forever.

Looking around for Drupal modules, you get quickly overwhelmed: just for Drupal 11 there are 205 modules mentioning “notification”, 98 for “notify”, 117 for “subscribe”, and 621 for “message”. OK, there are overlaps, and certainly false positives. But it’s fair to say that one can find hundreds of modules in this space. And even if it were just a few dozen, that’s confusing site builders and developers alike, and it’s not really a notification solution for Drupal as such.

This is a huge problem:

• For each type of notification, the site builder needs to find a separate module.
• Each of those modules needs to be configured individually.
• Most of those modules support just one delivery channel, most often that’s just email.
• Imagine, every type of notification you receive from the same Drupal site, looks different.
• Digesting notifications, or providing an in-site notification feature with history, isn’t possible.
• The mountain of technical debt grows too quickly, and the headaches around the next major Drupal core update are foreseeable.

ECA comes to your rescue

What has to be achieved around a unified notification framework in Drupal is a natural fit with how ECA deals with things. Looking into the “What”s from above once again, each one of them involves an event that get dispatched. New content, comments, error logs, user registrations, profile changes, groups, batches, etc. they all can be starting points for ECA models.

This is because every ECA model starts with an event. In combination with all the available conditions in ECA, it’s straightforward to define rules, which of the events are note-worthy. And conditions then also come handy when you need to determine, who needed to be notified. That can be according to user roles, or subscriptions, or any other kind of business rule that applies on any given Drupal site.

Moving on, using actions in ECA to collect data and compose messages. Those can then be delivered either immediately, or collected in e.g. user data tables for postponed delivery in an aggregate. And if such delivery happens by email, either of the email modules in Drupal can be leveraged. But the beauties are, that every such notification email looks the same, and the site builder configures the email setup like SMTP or otherwise just once.

For those who need different or additional delivery channels like SMS, Slack, PushOver, or else, can either use an existing module for that, if they offer action plugins that ECA can use, or the brand-new orchestration initiative can be used to push notifications to any external tool that one can possibly think of.

Instead of using dozens of modules to manage notifications, everything can be configured with a single module, ECA. This reduces technical debt, ensures unified messaging, and provides a single interface to manage configuration and stay on top of everything.

This needs to be more convenient

Agreed, this would be a ridiculous approach if every site builder had to build their notification flow themselves, and from scratch. Instead, we should develop a suite of ECA models that cover all of the above requirements, and provide them as recipes that follow best practices.

Having said that, most sites will have their own ideas on how they want to do things, and that’s where they can use the ECA UI to modify the provided ECA models and adjust them to fit their own requirements. And that’s where a more modern, more intuitive UI is required, that we’re in the process to define and build.

Knowing what users are going to do with that tool is a prerequisite for UX and UI research and development. Managing notifications is therefore are perfect use case of what users desperately want to do on their Drupal sites, and ECA is almost there. But it needs that usability push. Come and help us to get this done. Join us in Drupal Slack, or comment below, or send us messages using the contact form. We’d love to hear back.

Join us on Drupal Slack