---
# System prepended metadata

title: Notifications

---

# Notifications

The goal of this document is to specify the logical design for notifications service within the Alkemio platform.

The service specifically targets out-of-band notifications, such as e-mail, sms, push notifications.

Notes: 

* Notifications events are consumed from a RabbitMQ AMQP PubSub implementation (consuming a queue)
* The notification service is not handling GraphQL subscriptions - these are managed on API (GraphQL) level
* Notifications are transient and not guaranteed (even if they will work 99.9%); they are a convenience. There is no state management. 


Aspects to consider:
- Email templates should be supported
- SMTP relay should be supported and is first priority

## Notifications Design

### [Architecture](https://miro.com/app/board/o9J_lvqstFI=/)

The architecture of the notifications is the following:

1. GraphQL mutations publish events to the alkemio-notifications event queue on RabbitMQ through AMQP.
2. RabbitMQ queue alkemio-notifications is connected with a RabbitMQ exchange to support AMQP PubSub.
3. AMQP RabbitMQ consumer (Alkemio Notifications Service) reads the event and sends an event to a 3rd party service for out-of-band communication. There are different strategies how to send it and channels to send to. The implementation is wrapping notif.me, using NestJS.

### Email templates

Email templates can be implemented with [notifme-templates](https://github.com/notifme/notifme-template). A template would look like:

```jav    
    email: {
      from: '{{emailFrom}}',
      to: '{{user.email}}',
      subject: 'Welcome {{user.firstname}}',
      html: `{% extends "templates/_layouts/email-transactional.html" %}
        {% block content %}
          Hi {{user.firstname}},<br><br>
          We're very happy to welcome you on board.<br><br>
          See you soon!
        {% endblock %}`
    }
```

### Events

| Event Name                            | Purpose                                    | Message types / audience                             |  Payload   |
| ------------------------------------- | ------------------------------------------ | ---------------------------------------------------- | --- |
| COMMUNITY_APPLICATION_CREATED         | New application for a community            | User that signed up; Community admins; Global admins |HubId, ApplicationId     |
| COMMUNITY_APPLICATION_UPDATED         | Application approved / rejected / archived | User that signed up; Community admins; Global admins |HubId, ApplicationId        |
| ORGANIZATION_VERIFICATION_REQUESTED   | Org verification has been requested        | Org admin/owner; global admins                       |OrgId   |
| ORGANIZATION_VERIFICATION_UPDATED     | Org verification has been updated          | Org admin/owner; global admins                       |OrgId     |
| USER_PROFILE_CREATED                  | New user has signed up                     | User; global admins                                  |UserId     |
| COMMUNICATION_UPDATE_MESSAGE_RECEIVED | User has received an update message        | User                                                 |HubId, CommunityId     |
| OPPORTUNITY_CREATED                   | A new opportunity has been created         | Challenge / Ecoverse admins / Global Admin           |HubId, OpportunityId     |


Note: EventAgent(User)Id is sent in all payloads.
## Open discussion points

* Management of notification preferences
    * Users need to be able to control the notifications that they receive
* Authorization 
    * Framework needs to ensure that only users that are eligible to receive events do so