Skip to main content

Email Notification Logic

Case 1: New Case Creation

When a new case is created in the system, an automated email notification is triggered and sent to the appropriate recipients. The business logics governing this process is outlined below:

    1. The system first verifies whether the newly created case is associated with a specific company.

    2. If a company is linked to the case, the system attempts to identify all users assigned to that company.

    3. If company users are found, they are designated as the recipients of the notification email.

    4. In the event that no company users are available, the system proceeds to identify users holding a legal role (e.g., lawyers) to receive the notification.

    5. The system then sends an email with the subject “Neuer Hinweisgeberfall” to the determined recipients, informing them of the newly created case.

Case 2: Follow-Up Case

This process ensures that cases in the system are not left unanswered for too long. When a case remains inactive (i.e., no response has been given) for several days, the system automatically sends reminder emails to responsible users daily to follow up. This helps maintain timely responses and accountability.

The system checks all open cases every few hours. A follow-up email is sent if a case has not received a reply within 3, 5, or 7 days. The reminder urgency depends on how long the case has been idle.

The business logics governing this process is outlined below:

  1. If the case is assigned to a company:

    • It checks for users linked to that company.

    • These users receive a follow-up reminder email.

  2. If no company users are found:

    • It checks whether there are any lawyers already linked to the case.

    • If found, those lawyers receive the reminder.

Case 3: Overdue Case

This process is designed to ensure that all cases created in the system are actively followed up and do not remain unresolved for an extended period. Specifically, it targets cases that have been open for more than 80 days without closure and sends automated reminder emails daily to the appropriate recipients.

The business logics governing this process is outlined below:

  1. Identify Overdue Cases

    • The system checks for all open (not closed) cases where the created_at date is 80 days or older.

  2. Determine Recipients for Each Overdue Case

    a. Company-Linked Cases

    • If the case is linked to a specific company, the system:

      • Retrieves all users associated with that company.

      • Sends an overdue case notification email to each of those users individually.

    b. Cases Without Company Users

    • If no users are associated with the company, the system:

      • Retrieves users linked to the case directly (e.g., lawyer).

      • Sends the reminder email to each of those users.

Case 4: Assigning a User to a Case

This process allows authorized users to assign a specific user (lawyer) to a whistleblower case. Once a user is assigned, the system sends them an email notification to inform them of their new responsibility. The business logics governing this process is outlined below:

  1. Validate for Duplication

    • Before inserting, the system checks for existing records to ensure the same user is not assigned to the same case multiple times.

    • If a duplicate is detected (based on a unique constraint), an error is returned.

  2. Create Case Assignment

    • If no duplication exists, the system saves the user-case assignment in the database.

  3. Send Notification Email

    • Once the assignment is successful, the system triggers an immediate email to the assigned lawyer.

Case 5: New Case Message

This process ensures that all parties involved in a whistleblower case are promptly informed when a new message is posted in the system, regardless of whether it was sent by a user or by the company. The email notification process is triggered when a new message is submitted via the system. The business logics governing this process is outlined below:

  1. Message Creation
    • A new message is created and associated with an existing case.
    • The system determines the sender type based on the SenderTypeID:
    • 1 = Message sent by the User (Whistleblower)
    • 2 = Message sent by the Company

  2. Case Status Update

    • If the sender is the user, the case status is updated to REPLIED.

    • If the sender is the company, the case status is updated to NEW, and the case’s last_reply timestamp is updated.

  3. Email Notification Logic

    📤 When the whistleblower (user) sends a message:

    • The system sends an email to the assigned lawyer if there is no company user has been assigned to the case. If the case has been assigned to a company user, then the system will sends an email to the company user.

    • Only sent if the case is not anonymous.

    • Subject: "Neue Nachricht im Anfrage/Meldeportal" (German: "New Message in the Reporting Portal")

    • The email includes a secure login link for the whistleblower to view the response.

    📤 When the Company sends a message:

    • The system checks whether any company users are linked to the case’s associated company.

      • If company users are found:

        • An email is sent to each company user.

    • All emails include a login link for internal users to view the new message in the system.

Case 6: Reset Password

This process provides users with a secure method to reset their password if they have forgotten it. It ensures identity verification through email and allows temporary access to a password reset form via a time-limited token. This logic is triggered when a user submits a password reset request through the frontend by providing their email address. The business logics governing this process is outlined below:

  1. Input Validation
    • The system accepts an email address as input.
    • It verifies that the input is in a valid email format.
    • If the format is invalid, the request is rejected with an appropriate error message.
  2. User Lookup
    • The system checks if the provided email address belongs to a registered user in the database.
    • If the email does not match any existing user, the system returns a generic unauthorized response (e.g., “invalid email”) to prevent email enumeration.
  3. Email Notification
    1. The system sends an email to the user with the subject "Passwort zurücksetzen" (German for "Reset Password")

Back to top