Overview
This Emersion fundamentals article introduces users to Events in Emersion.
The Emersion Events module is more than a notifications system, although this is what it is frequently used for. Events automate many activities that typically support Emersion's features. Some examples of how events can be used include:
- sending the customer their invoice via email
- scheduling a report to be sent to a nominated email address every 2nd Monday
- sending a customer a welcome email once they have signed up
- send an SMS to a customer when they have reached a given % of their available usage
- print a form (web page) on demand
- shape a customer's internet service
- shift users from one account group to another
- notify a user of a systems failure when attempting to complete a specific task
- effect a password change for users who have forgotten their password to the End User Portal
- send a bulk notification to a list of recipients using Email Out or SMS Out
- generate late payment fees for ageing unpaid invoices and notifying the customer
Emersion provides all service providers with all the necessary events for you to use the system effectively. We have events for Wholesale and Retail Service Providers. We also have events specific to service types, optional modules and features. These will be added as part of the subscription to the module.
How are Events Used in Emersion?
Here are some basic examples.
- Sending the customer their invoice via email after it has been approved.
- Scheduling a report to be sent to a nominated email recipient every 2nd Monday.
- Generate late payment fees for ageing unpaid invoices and notifying the customer
- Sending an SMS to a service user when they have reached a given % of their available usage.
- Displaying specific content on screen in a printable format during a defined step of a process.
The Event Library
If you want to know more about an individual event type, or are looking for an event type to solve a specific problem, the Event Library is place to start your search. If you are interested in an event that is not part of the standard list that are already mapped, please raise a QR ticket via the Customer Support Portal.
Anatomy of an Event
An event comprises three components:
| Component | Description |
|---|---|
| conditions | Conditions are the predetermined status of a dynamic object, or instance, that trigger an event to occur. E.g. a customer reaches 90% of their usage allocation for a given period. |
| trigger | A trigger is the initiation of an event when the conditions of the event have been satisfied. E.g. Your customer's invoice becomes overdue today (the predefined condition is met), triggering the event, therefore the system will initiate an email (perform an action) to advise the customer that their invoice is overdue. |
| action | An action is what the system will do once the condition is met. Each action occurs once a template has been set up and the event enabled. |
Account-Based vs Service-Based vs Function-Based Events
- Some events are account-based, meaning they are notifications regarding, or to do with, the account. For example, the Account Created event will fire a notification when a new account is created in Emersion. This is intended to go to the primary contact of the account and is used to provide a welcome to your new customer.
- Some events are service-based, meaning they relate to the service in question. For example, the Bolt-on Activation event is fired when a customer's bolt-on is activated. Bolt-ons are specific to a single service. It has no direct relationship to the account, or the account contact. Therefore, it will send the notification to the contact associated with the individual service (Service-level contact).
- Some events are function-based, meaning they relate to a function or module. For example, some Service Desk events will notify the ticket creator, rather than a contact associated with the account or the service.
Unprocessed Events vs Processed Events
It is important to understand the difference between processed and unprocessed events.
| Unprocessed events | An event has been created. The content has been generated from the event template. The notification has not been physically transmitted via the chosen mode of communication (Email, SMS, On Screen) The notification is sitting in a queue waiting to be sent; or the notification will not be sent due to the reasons below. |
| Processed events | An event has been created. The content has been generated from the event template. The notification has been physically transmitted via the chosen mode of communication (Email, SMS, On Screen) |
Event Processing
Events are not always processed immediately. There are a few reasons Emersion either queue events and delay processing, or not process them at all.
- SMSs are sent only during acceptable allotments of time.
- Where an event is configured to send a notification to both a service number and the primary contact of the account, it will only physically transmit one. In this instance, two events are created but only one is processed.
Emersion will not send SMS events between 8:00pm - 9:00am AEST/AEDST (which ever applies) 7 days a week. Service providers can override these times by sending a request to Emersion.
The System Event Queues page in Cumulus helps users identify what events have been processed and which have not.
Event Types vs Events
An event type, in its simplest explanation, is a type of event that Emersion provides service providers. Event types have a name, a description and capabilities that are described above. It can be enabled by Emersion for any service provider account. Some event types will be mapped to a service provider account more than once.
Events are instances of that event type. For example, the Invoice Delivery event type is used to send Customer A an invoice in January, then in February, in March, and so on. Each month when an invoice is approved, it will trigger a new event to be created.
Therefore customer A will have 3 events created for each of the 3 months that the event type was used to send the invoice to them.
| Event Type | Event | Where is it recorded? |
|---|---|---|
| Invoice Delivery | An event is triggered on January 3rd and the invoice is sent to the customer | Customer Notes on 03 Jan |
| Invoice Delivery | An event is triggered on February 3rd and the invoice is sent to the customer | Customer Notes on 03 Feb |
| Invoice Delivery | An event is triggered on March 3rd and the invoice is sent to the customer | Customer Notes on 03 Mar |
Events and Account Profiles
Most events types are bound to an account profile. If the customer does not belong to the account profile the event mapping has been bound to, the event will not be triggered, even when the triggering conditions have been satisfied.
Service providers who are looking to use multiple account profiles must contact Emersion Sales. Emersion will provide a quote for mapping a complete second set of event types mapped to each account profile.
The positive impact to service providers is that they can customise each template for users in different account profiles.
The negative impact to service providers is having to maintain a set of templates for each account profile.
Email From Your Domain
Before you can send email from the events system, your domain has to be configured in Cumulus.
See Email Domains (DNS Record configuration) for the How To instructions.
The Sender's Address
The email Sender field within the Events module (includes the Email Out feature) is subject to rules and validation.
Do not use xxxx@emersion.com or xxxx@emersion.com.au for any Sender email addresses.
The system validates the Sender address against:
- the configured domains.
- Case sensitivity: If the domain is mycompany.com.au, a sender address of noreply@MyCompany.com.au is permitted.
- Sub-domains. Sub-domains are supported provided the domains are verified. For example, a if an email domain of mycompany.com.au is added, a sender with a subdomain is allowed. i.e. testme@subdomain.mycompany.com.au is permitted.
Further validation rules check the following and displays error messages accordingly in the event that the sender's address fails validation.
- Is the sender's address a valid RFC email address?
- Has the domain been configured in Emersion?
- Has the mail domain been registered with Amazon (verified or otherwise?)
- Has domain status been verified?
- Has mail from been verified?