# Activity Feed Source: https://v0.x-docs.novu.co/activity-feed/introduction Monitor all your activity from one place ## Introduction Novu provides a notification activity feed that monitors every outgoing message associated with its relevant metadata. This can be used to monitor activity and discover potential issues with a specific provider or channel type. ## Viewing a specific subscriber's activity To use a subscriber's activity feed you can filter the feed by using the subscriberId or email. This will show only the relevant data for this particular subscriber. To do this, just enter the `subscriberId` or the 'email' of the subscriber you want to get info of and then click the 'search' button on the right-hand side as shown in the image below: ## Filter by workflow or channel The activity feed allows you to filter messages based on the associated workflow or channel. This is helpful when you want to assess or debug a particular workflow and its behaviour. Filtering by workflow or channel is quite simple. Just go to the Workflow dropdown (if you want to filter by workflow) or the channel tab (if you want to filter by channel) and select the corresponding workflow or channel and click the 'search' button on the right-hand side as shown in the image below: ## Troubleshooting with the activity feed The activity feed also shows if a transaction is failing. You can see why a transaction is failing and rectify it. For example, take a look at the following image: You can see that an SMS notification has failed to get delivered. Clicking on it opens the execution details and the reason why that transaction failed This can help troubleshoot the problem and comes in handy at the time of distress. ## Digest info in the activity feed If you’re using our digest notifications functionality, you’ll be able to see all the digest-related information in the activity feed. Some of the information related to digest present in the activity feed is: * Digest step delay * Digesting start time * Digest triggered events details * More digest execution details From here, you can see the details of ‘digest triggered events’ to see exactly which events were digested and the content of the notification you sent, as shown below: ## Trigger Event Lifecycle ### **Trigger request** The request contains details such as the identifier for the template, the list of subscribers who will receive the notification, the payload of the notification, and any overrides that need to be applied. ### Trigger endpoint After the request is sent to the `/event/trigger` endpoint, the initial step involves mapping and validating the subscribers for that event. Following that, we validate the template and steps based on the active status or draft template flag. Once the validation process is complete, the attachments are uploaded to the storage service. Next, the trigger event with mapped subscribers and attachment links is appended to the **trigger event queue**. By queuing the events, we can achieve faster response times. ### **Trigger event processing** When the event is picked up by the **trigger queue worker** we process it. For every subscriber listed in the trigger event, we create a notification entity and the corresponding jobs based on the notification template steps. The notification contains data related to the organization, template, subscriber, and event payload. It is updated with a channels field that is generated from the steps. ### **Jobs** Every job is created according to the steps outlined in the template. If the template contains a digest step, the **filtering logic** is applied to produce the appropriate jobs array depending on the type of digesting: **regular** or **backoff**. # Trigger Event Lifecycle Source: https://v0.x-docs.novu.co/activity-feed/trigger-event-lifecycle Managing Trigger Events from Request to Processing ## Trigger Request A trigger request is the initial step in handling a trigger event. It contains crucial details such as the template identifier, a list of subscribers who will receive the notification, the payload of the notification, and any overrides that need to be applied. ## Trigger Endpoint Upon sending the request to the `/event/trigger` endpoint, a series of essential steps are initiated: 1. **Subscriber Mapping and Validation:** The first step involves mapping and validating the subscribers for the specified event. This ensures that notifications are sent to the correct recipients. 2. **Template Validation:** Following subscriber validation, the template associated with the event is validated. This validation process considers factors such as the active status or draft template flag to determine if it meets the necessary criteria for processing. 3. **Attachment Upload:** Once the validation process is successfully completed, any attachments associated with the event are uploaded to the designated storage service. 4. **Event Queuing:** The trigger event, now enriched with mapped subscribers and attachment links, is appended to the **trigger event queue**. This queuing mechanism optimizes response times, ensuring efficient event processing. ## Trigger Event Processing When an event is picked up by the **trigger queue worker**, the processing phase begins. Here's what happens: * **Notification Entity Creation:** For each subscriber listed in the trigger event, a corresponding notification entity is created. This entity contains essential data related to the organization, template, subscriber, and event payload. * **Job Creation:** Based on the notification template's defined steps, jobs are generated. These jobs are responsible for carrying out specific tasks related to the event notification. Additionally, the notification entity is updated with a "channels" field generated from these steps, indicating the communication channels through which notifications will be sent. ## Jobs Jobs play a pivotal role in the trigger event lifecycle. They are created based on the steps outlined in the notification template. Depending on the presence of a digest step, the following logic is applied: * **Digest Step:** If the template includes a digest step, filtering logic is applied to produce an appropriate array of jobs. This logic differentiates between two types of digesting: **regular** and **backoff**, each serving distinct purposes in event processing. ## Job Statuses | Status | Description | | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **PENDING** | This status is assigned to a job before it is added to the worker queue. It indicates that the job is waiting to be processed. | | **QUEUED** | After the initial validation and just before adding a job to the worker queue, it is set to `QUEUED`. This status signifies that the job is ready for processing but is awaiting its turn in the queue. | | **RUNNING** | When a job is picked up by a worker from the queue, its status is changed to `RUNNING`. This indicates that the job is currently being processed by a worker. | | **COMPLETED** | Once a job has been successfully executed and processed, its status is changed to `COMPLETED`. This signifies that the job has been successfully completed. | | **FAILED** | If a job encounters an issue during processing or execution, its status is changed to `FAILED`. This indicates that the job has not been successfully completed, and there may have been errors or problems during processing. | | **DELAYED** | The `DELAYED` status is applied to specific types of jobs, such as `digest` or `delay` jobs, to indicate that they are delayed and not immediately processed. For `digest` jobs, it means that the digesting process is running or scheduled for a later time. For `delay` jobs, it signifies that the job is set to be executed at a specified delay time. | | **CANCELED** | When a job is canceled for any reason, its status is set to `CANCELED`. This indicates that the job will not be processed further and is effectively removed from the processing queue. | | **MERGED** | The `MERGED` status is assigned to events that are part of a `digest`. It indicates that an event will be merged into the digesting event. In a digesting process, there is typically a primary or initial event that serves as the digesting event, and subsequent events are merged into it. Instead of having a separate `COMPLETED` status for these merged events, they are marked as `MERGED` to indicate their specific role in the digesting process. | | **SKIPPED** | The `SKIPPED` status is used in the context of backoff versions of digesting. In this scenario, the first event's digesting is skipped, and the second event takes on the digesting role. The `SKIPPED` status is applied to the first event's digesting, indicating that it was intentionally skipped in the digesting process. Subsequent events may be merged into the second event's digesting process, as explained with the `MERGED` status. The `SKIPPED` status helps differentiate the skipped event from others in the digesting sequence. | **Example:** `PENDING` `QUEUED` `RUNNING` `RUNNING` `COMPLETED` # Novu Architecture Diagram Source: https://v0.x-docs.novu.co/architecture/diagrams # Novu Architecture Diagram powered by [terrastruct](https://terrastruct.com) and D2 If the diagram below is not rendering, please [click here](https://app.terrastruct.com/diagrams/1895866270) to view it on terrastruct.com.