One of the most powerful features added to Event Espresso 4 is the new messages system. In this post, we’re going to give you an overview of what this new system is, some of the terms you’ll come across when working with it, and tell you why we think Messages is so powerful.
What is “Messages”?
The messages system is the engine that powers all the notifications that go out from EE when triggered by different things happening on your Event Espresso powered website. By different things I mean things like:
- when person registers for an event
- when a payment is made
- when a registration is cancelled
- etc.
When one of these things happens (we call them triggers) then the messages system kicks in to prepare and send out notifications about what happened. At this point there are a number of components in the messages system that play a role in assembling and sending a message. Let’s take a look at what those components are:
Message Types
Message Types describe the kind of message that is being sent and describe what the content of the message will be about. In Event Espresso there are currently (as of the time of writing this document) 8 different message types. Three for payment related messages (payment received, payment reminder, payment declined), and five registration related messages (registration approved, not approved registration, registration pending, registration declined, registration cancelled). Message types are attached to triggers
Messengers
Messengers describe the vehicle that delivers the messages. The most common delivery vehicle pretty much all of us are familiar with is email! This is why email is the first and currently only messenger used by the messages system however it is important to note (and I’ll expand on this later) that it is not intended to stay that way.
Contexts
A context describes who or what receives the message. You won’t see the word context much in the UI for messages because the labels for contexts are dynamic and are defined by message types (but can also be overridden by messengers). When defined by the system, they will take on a label that more accurately describes the intent. For instance with all the current message types in the system there are up to three contexts available (which are labelled recipients in the ui): event admin, primary registrant, and registrant. The purpose of the context is to empower you to be more granular in the messages you send out.
As an example, for the Registration Approved message type, the event admin may receive summary details of the registration that was approved, whereas the primary registrant will receive information pertaining to the whole group registered, and the registrant just receives details on their specific registration for the event.
Keep in mind that the number of contexts available per message type and messenger combination is variable depending on how they’ve been designed by us (or the third-party plugin for the messages system). For instance, we didn’t include the registrant context with any of the payment message types because its really only the primary registrant (the one who completed the registration) who is concerned with paying for the tickets.
Message Templates
Message Templates are the blueprint for what the message will look like when its assembled. This is a very powerful component to the messages system because it allows for more granular control of the “looks” of outgoing messages.
The important thing to remember about message templates, is that there is a message template for each messenger, message type, and context combination. So for example, there is a template for the email messenger, registration approved message type, and Event Admin recipient (context).
Each message template will have fields that are defined by the messenger primarily but also supplemented by the message type if there are any additional fields required by the message type. For instance, all email templates will have to, from, subject and main content fields.
Note
You will see other fields like
[event_list],
[attendee_list] etc in the message templates. These are special fields related to messages
shortcodes which I’ll be getting to in a
later section.
When you activate Event Espresso, the message system comes with default global templates out of the box that will help you get started right away with your events without having to do any editing. However you are able to edit any of these templates.
Difference between Global and Event specific templates
One more powerful feature with the new messages system is that by default, global templates will apply to every trigger happening with an event. So that means, for example, when a registration is approved (the trigger), all the global templates using the Registration Approved message type get sent. However, the messages system also allows Event Authors to create a custom template for that message type to be used only for that event. If this is done, then when the Registration Approved message type is triggered the message template for that event is used instead of the global message template. This allows you to differentiate different automatic messages for different events.
Message Shortcodes
Message shortcodes are special snippets of text that allow for precisely controlling how dynamic content will display in the message template. If you are familiar with how WordPress shortcodes work then using these shortcodes should be fairly straightforward. Shortcodes such as [EVENT_NAME], [REGISTRANT_FNAME], [EVENT_AUTHOR_FORMATTED_EMAIL] all provide an easy way to indicate where dynamic content will be inserted when messages are sent.
There are also special shortcodes that we call list-type shortcodes. These are shortcodes such as [ATTENDEE_LIST], [EVENT_LIST], and [QUESTION_LIST]. These shortcodes are special because when you use it, you are indicating that this is where you want a list of items to be displayed in your template. When the message generator gets to this shortcode, it will signal it to look for a corresponding field in the template to know how to parse each item in the list. So when you see a field in a message template that is labelled with [event_list] then you know that when the [EVENT_LIST] shortcode is parsed, the generator will look in the [event_list] field to know how to parse each event item. Super powerful!
What’s Next?
We intentionally built the messages system so it would act more like a framework for being able to rapidly add different kinds of messengers and message types for Event Espresso. We also hope that third party developers will also find this to be a useful tool for adding their own messengers and message types into the system. Want some examples?
- What about a Facebook messenger for posting notifications to a Facebook page?
- What about a Twitter messenger for posting notifications to your event twitter account?
- Or maybe a messenger to connect data from different triggers with your favorite accounting app via their API?
- Or maybe a messenger to connect Event Espresso with Zapier or If This Then That.
Here’s some message types we are working on for future iterations of EE4:
- a newsletter message type that will allow you to send batch emails to all registrations or contacts (or subsets meeting certain criteria)
- an automated event notification message type that let’s contacts know when you’ve posted a new event.
- automated payment reminder message type that works similarly to the current payment-reminder message type except that this new one will allow you to set a schedule for sending messages to people who haven’t paid for their ticket yet.
There are all kinds of ideas we’ve heard from customers about notifications and how they should work and we’re excited because we now have a solid framework to build out some of those ideas (and for others to build their ideas). Have you tried the messages system in EE4 yet? What do you like/dislike about it? We’d love your feedback!
