Overview

The Message concept in NEON refers to any form of messaging we want to send, such as Email and SMS.

Terminology

Message Servers. This is a low-level Entity Type (MESSAGE_SERVER) which is set up once (by SPIKA), and which contains information about which messaging platform should be integrated with (Mailchimp, AWS, …) and how to connect. Additional message integrations can be added later and separate external programmes will be implemented to deal with each of these integrations. In the first version we only support AWS emails. There is no need for Config pages for Message Servers since it’s such a low-level task which is set up once and then left.
Message Templates. This is also an Entity type (MESSAGE_TEMPLATE). A Messge Template is set up for each type of email or SMS. This is often done by Marketeers. The Message Template contains the definition and content, along with any parameters that may be needed. Each Message Template must be linked to a specific Message Server.
Message Instance (or just Message). Each individual message (such as email) that is sent out. They link to a specific Message Template, and get stored in ng_message_tb, where they will be picked up and sent out by the associated Message Server.
Message Batches. When multiple Messages are sent out, for example when sending to a whole list then they will be grouped together as a Message Batch.

Communication Types

When setting up a Message Template you have to specify what type of Message it is. This is part of the Message template’s configuration, and it is not an Entity Sub-Type. These are the types available:

Marketing. These Messages require the Members to be opted in. It also requires a Subscription List reference to verify the opt-in status against.
Functional (also often called Transactional or Service). These messages are sent to a Member regardless of if they’re opted in or not. Examples of such messages are order confirmations, forgotten password emails etc.
Contact. This type is used for Contact Us emails, GDPR requests, Complaints etc. They work exactly the same way as Functional, with the exception that they can’t be sent in bulk (such as to an entire List).
System. This Message type differs from all the others in that it’s not linked to Members. It is used for global and general system and portal related status updates, alters and errors etc, or to signal to a logged in User that a background process has completed.

Sending Messages

Messages can be sent in several different ways:

Through triggers. The message gets triggered by some event (Message Trigger) and is sent to one person
By Journeys. If the journey contains a Message step, it gets sent to one person
By Jobs. A background job can trigger messages to be sent out to one or many people
Through API endpoints. May be sent to one or many people, depending on the call
Through the Portal user interface

Testing Messages

The server/APIs support the ability to send test messages. Test messages require a specific Member Lookup Id (to know which Member to test) but is sent to a different destination (email address).

Message Body or Json attributes

Some email servers require the Body to be prepared beforehand, whereas others has the body/template defined and just want a list of Users to send to, possibly together with a Json attribute model.

NEON Messaging supports both body and/or Json attributes.

When configuring the Message Server you specify if the body attribute should be presented in the template or not.

You can also configure (both in the Server and in each Template) any number of Json attributes that can be used together with or instead of the body.

If a body is present it will be parsed using the template engine, with any personalisation or conditions resolved. This happens when the new Message is triggered, and the resolved body will then be stored in the message queue for later sending.