workflow.mdx

title	icon
Workflows	bezier-curve

This document provides two key workflows for the Notification Service:

• Notification Onboarding Workflow
• Notification Processing Workflow

Each workflow is explained in detail and references a diagram illustrating the sequence of actions and system interactions.

---

1. Notification Onboarding Workflow

Purpose
The onboarding workflow enables a client (consumer) to register or onboard new Products and optionally Organizations under these Products. This process is essential for generating the unique API credentials (keys and IDs) required for all further Notification Service interactions.

Key Steps

The client submits a request to add a new Product. The Notification Service stores the Product details and returns a unique Product API Key and Product ID. If the Product requires Organizations (typical in B2B scenarios), the client can create one or more Organizations under that Product. The service then stores each Organization’s details, linking them to the Product, and generates Organization credentials (Org API Key & Org ID). With credentials generated, the client can start using the notification endpoints.

Diagram

---
config:
  layout: fixed
---
flowchart TB
    A["Client / Consumer"] --> B["Create Product Request"]
    B --> C["Notification Service - Onboarding Component"]
    C --> D["Persist New Product Details in DB"]
    D --> E["Generate Unique Product API Key & Product ID"]
    E --> F["Provide Product API Key & Product ID to Client"]
    F --> G{"Does Product need Organizations?"}
    G -- Yes --> H["Create Organization Request"]
    H --> I["Notification Service - Onboarding Component"]
    I --> J["Persist New Org in DB and link with respective product"]
    J --> K["Generate Unique Org API Key & Org ID"]
    K --> L["Provide Org API Key & Org ID to Client"]
    G -- No --> M["Ready to Use Notification APIs"]
    L --> M
    ```

---

## 2. Notification Processing Workflow

**Purpose**  
Once the client has valid Product and/or Organization API keys, they can trigger notifications to be sent through various channels (Email, SMS, Push, etc.). This workflow shows how the system validates credentials, processes notifications (including queueing), and handles success/failure outcomes.

**Key Steps**  

<Steps>
  <Step title="Trigger API">
    The client calls the Notification Service’s trigger endpoint, supplying valid API keys and the notification payload.
  </Step>
  <Step title="Validation">
    The service checks the Product/Org API keys for authorization and also validates the request body.
  </Step>
  <Step title="Audit Logging">
    Key events (triggering, processing, delivery) are recorded for traceability.
  </Step>
  <Step title="Queueing">
    The message is placed into a queue with the appropriate priority, returning a Request ID for client tracking.
  </Step>
  <Step title="Delivery Attempt">
    The service (or a worker) attempts delivery. Success or failure is noted in the audit logs.
  </Step>
  <Step title="Retry & Error Handling">
    On failure, the system retries according to a predefined policy before ultimately logging the final outcome.
  </Step>
</Steps>

**Diagram**  

```mermaid
---
config:
  layout: fixed
---
flowchart TB
    A[Client 
     with valid API Keys] 
        --> B[Trigger Notification API]

    B --> C[Notification Service]
    C --> D[Validate Product/Org Keys & Authentication]
    D --> E{Valid?}

    E -- No --> F[Return: 401 Unauthorized]
    E -- Yes --> G[Start Notification Processing and log event in Audit Trails]

    G --> H[Build Notification Payload for respective channel Email, SMS, Push, etc.]
    H --> I[Push event into Queue with respective priority and log in Audit Trails]
    I --> N[Return: Request ID to Client for further tracking]
    I --> J[Delivery Attempt on consuming the event and log status in Audit Trails]

    J --> K{Success or Failure?}
    K -- Success --> L[Log Success in Audit Trails]
    K -- Failure --> M[Retry & Error Handling]
    M --> L[Log Success/Failure in Audit Trails]

    ```

---

### Final Notes

- **Security & Authorization**: Always ensure valid API keys are included with each request.  
- **Multi-Tenancy**: B2B products may use multiple Organizations, while B2C products typically do not require Organizations.  
- **Audit Trails**: Every major event (creation, updates, notification triggers, retries) is recorded to facilitate debugging and compliance.  
- **Scalability**: Leveraging a queue-based architecture ensures high throughput and fault tolerance for large-scale notification deliveries.

By following these two workflows, you can seamlessly onboard your Products and Organizations and reliably send notifications to your users. If you have any questions or need further assistance, please let us know.

Loading