Good News - over the holiday period and in recent weeks, there have been several updates on Daato's platform!

The updates range from improvements in the different modules, but also at platform level, and we will explain all of them in this article.

Platform updates:

New authentication flow

Why?

We have made the login flow even more secure and easy to deal with, also for users who forget their passwords.

What did we change? We adjusted the login flow, here is how it works:

1. User Invitation
   • Users cannot sign up independently.
   • Only invited users can access the application.
   • An invitation email is sent to the user, containing a link to set up their password.
2. Invitation Email
   • The invitation email includes a unique link.
   • The link directs the user to a page where they can set up their password.
   • Setting up the password confirms the user's invitation.
   • Invitation link is valid for 7 days.
3. Accessing the Tool
   • Users must provide their email address to access the tool.
   • If the email address belongs to a user who hasn't accepted their invitation:
     • The user is redirected to a page to provide a one-time code.
     • A one-time code is sent to the user's email.
     • Upon entering the code, the user is directed to the password setup page.
   • If the email address belongs to a user who has already confirmed their invitation:
     • The user is directed to a login page.
     • The user can enter their password or choose to log in using a one-time code.
     • If the one-time code option is selected, a code is sent to the user's email.
4. Data Request Notifications
   • Invited users who haven't accepted their invitations can still receive data requests.
   • When such a user receives a request, they get an email notification with a link to the request's page.
   • Before accessing the request page, the user must go through the authentication flow described in section 3.
5. One-Time Codes
   • One-time codes do not expire over time.
   • Each one-time code can only be used once.

In-app notifications

Why? 

These updates make it easier for users to stay informed about important activities and actions within the platform, ensuring they never miss a critical update.

What did we change?

1. Notifications Icon:
   • A new notifications icon has been added to the top navigation bar for easy access.
   • It will show a red badge if unread notifications are available.
2. Notifications Drawer:
   • Clicking the notifications icon opens a drawer that shows a list of notifications for the user.
3. Unread Notifications:
   • Unread notifications are highlighted to help users easily identify them.
   • If there are unread notifications, the notifications icon will display a badge.
4. Marking Notifications as Seen:
   • Users can mark all notifications as seen with a single click using the “Mark all as seen” button.
   • Alternatively, individual notifications can be marked as seen by clicking on them or their action links.
5. Organized by Date:
   • Notifications are grouped by the date they were created, with the newest ones at the top.
   • Users can view more notifications by clicking the “Load older” link at the bottom of the list.
6. Notification Details:
   • Each notification includes a timestamp, title, and description, which may contain specific details like names or other relevant information.
7. Notification Events:
   • Notifications are generated for key events, such as:
     • Request Received: Notifies the receiver when a new request is created, with a link to view the request details.
     • Request Answer Received: Notifies the sender when a request status changes to review, with options to view the request details or resend the invitation.
     • Request Email Bounced: Notifies the sender of the request when a new request notification email bounces, with a link to view the request details.
     • Invitation Email Bounced: Notifies the user who invites a new user when the invitation email bounces, with an option to resend the invitation (available only once per notification).

Bugs that were fixed

Expired old request notifications working again

ESRS-Module:

Mandatory fields when adding an IRO in step 2 of DMA

Labels under disclosure requirements and data points in Step 1 of ESRS report (these changes only apply to new ESRS reports):

Why?

What did we change? 

1. Labels for Data Points:
   • In Step 1 of the ESRS report, data points now display blue labels similar to those used for Disclosure Requirements.
   • Data points with the category "Voluntary" will show the label “Voluntary”.
   • Data points with the category "Phase-in" will show the label “Phase-in”.
   • Both labels can be displayed simultaneously if both conditions are met.
2. Information Tooltips:
   • All labels have an information icon that displays a tooltip with an explanation when hovered over.
   • Each type of label has a distinct explanation.
3. Justification Modal for Phase-in Data Points:
   • A new confirmation/justification modal has been introduced for phase-in data points.
   • This modal includes a field for providing justification.
   • The confirm button is only active when the justification field is populated.
   • Justifications are stored, and a history event is created when excluding the data point, similar to other data point categories.
4. Simplified Data Point Categories:
   • The "required" category for data points has been removed.
   • Data points can now only be marked as “Not Material,” “Voluntary,” or “Phase-in”.
   • Labels exist only for “Voluntary” and “Phase-in”. All other data points that are not Voluntary or Phase-in can be marked as not material and excluded by default.

Sub data points in Step 1 of ESRS report (these changes only apply to new ESRS reports):

Why? 

What did we change?

1. Sub-Data Points Overview:
   • Sub-data points represent individual questions asked within tabular data points, providing more detailed and specific information.
   • They are added when multiple data points defined in the ESRS requirements are combined within one table.
2. Inclusion Interface:
   • Users can easily manage the inclusion status of sub-data points through an intuitive interface.
   • By default, sub-data points follow the inclusion status of their parent data points. If a parent data point is excluded, its sub-data points are also excluded.
   • If a sub-data point is included, its parent data point will automatically be included as well.
3. Consistent Behaviour:
   • If a parent disclosure requirement is set to partial, some sub-data points will be marked as excluded automatically.
4. Justification for Exclusion:
   • When excluding a sub-data point, users must provide a justification, which is stored and can be reviewed or altered later.
5. User Interface:
   • Toggles next to sub-data points allow users to easily set their inclusion status.
   • The three dots menu next to sub-data points offers the same actions as for regular data points: history of changes and current justification (when excluded)
6. Configuration Updates:
   • For manual and aggregated data collection, questions within collapsible tables are shown only if the related sub-data points are included.

New DRs/DPs exclusion modal in Step 1 of ESRS report (these changes only apply to new ESRS reports):

Why?

What did we change?

1. New Modal Design:
   • Introduced a new modal for bulk exclusion of elements in Step 1 of the ESRS report.
   • Separate choice groups for Disclosure Requirements and Data Points.
2. Options Display:
   • Only relevant options are displayed:
     • Disclosure Requirements:
       • Non-material
       • No information to disclose
     • Data Points:
       • Voluntary
       • Non-material
   • Each option includes an information icon with a tooltip explanation.
   • The number of applicable DRs/DPs is displayed next to each option.
   • Options are disabled and greyed out if they contain 0 elements.
3. Enhanced Navigation:
   • “See all” next to each option opens a new modal with a detailed list of included DPs/DRs.
   • “Next” button is enabled only when an option is selected and navigates to a justification step.
4. Justification Step:
   • Added a blue explanation box above the input field for justifications.
   • “Confirm” button is enabled only if the justification is provided.
   • Upon confirmation, selected DRs/DPs are excluded in bulk, and justifications are stored.

Bugs that were fixed:

Data points not loading after user deletion

Supply Chain-Module

Supplier history

Why?

What did we change?

1. New "History" Tab:
   • The "History" tab (Verlauf in German) is now available in the supplier profile.
   • This tab is positioned right after the "Requests" tab.
2. Activity Tracking:
   • The "History" tab displays a list of the most recent activities performed for the respective supplier.
   • Activities tracked include:
     • Creation of a new supplier manually.
     • Importing a supplier.
     • Changes (additions, deletions, updates) to supplier profile information.
     • Sending requests to suppliers (preventative measures, SAQ, remedial actions, CoC).
     • Editing incidents (additions, updates, deletions).
     • Marking a supplier as safe.
     • Editing entity assignments.
     • Editing relationship manager assignments.
     • Updates to imports.
3. Detailed Event Information:
   • Each event in the history includes:
     • User: The individual who performed the action (e.g., who marked the supplier as safe).
     • Timestamp: The date and time when the action was performed.
     • Type of Action: The specific action taken.
     • Justification: Any justification provided for the action, if applicable.
     • Uploaded Documents: Any documents uploaded during the action, if applicable.

Bugs that were fixed:

SAQ score and risk level not included in export for filtered results

CO2-Module:

Pre-fill activities for your subsidiaries or other entities

Why?

Often users want to pre-fill some activities for their entities before the data collection, so that entity managers only need to fill in the consumption and not select the activities themselves.

What did we change?

1. The CO2 data collection now has two steps:
   • First you can add default activities and thereby pre-define some activities for your entities. This is an optional step.
   • Then you start the data collection and your entities can provide consumption values to the set activities (or add any other activities by themselves).
     
     
     
2. As admin or module manager, you can (optional step) add default activites in Step 1: 
   • Using the smart search, admins and module managers can add default activities. These activities will not contain a consumption value, this will be added by entity managers in Step 2. 
   • The activities are per default assigned to all entities selected in the given report, but this can be changed. The admin / module manager can define which activities should be assigned to which entities.
   • THIS STEP IS OPTIONAL! If you don't want to add any default activities, you can just complete this step and don't add any.
     
     
     
3. The data collection then continues to work as usual:
   • The data collection in Step 2 then works as usual. Entity managers and admins can enter data for activities they're assigned to or add additional activities.
   • Please note: 
     • Step 2 “data collection” is always locked until step 1 is complete
     • Step 2 will be complete if the data collection for all entities is marked as complete