This page will walk you trough a change log system for a multiple applications.
Welcome to our tutorial on building a robust logging system for your applications using rich text and templates! In the world of application development, logging plays a pivotal role in tracking changes, capturing important information, and maintaining a comprehensive record of activity.
Whether you're building a project management tool, a customer relationship management (CRM) system, or an inventory management solution, implementing an effective logging system is essential for ensuring accountability, transparency, and reliability. Access, audit, and change logs serve different purposes. Access logs document resource requests, audit logs monitor security events, while change logs record data modifications.
In this tutorial, we'll guide you through the step-by-step process of setting up a logging system using rich text and templates. You'll learn how to capture and store critical information, track changes over time, and present data in a clear and organized manner. By the end of this tutorial, you'll have a fully functional logging system tailored to your specific application needs.
The logging system operates by utilizing a transient single-select field that include all actions deemed loggable. When a loggable action is initiated, the system sets the transient field to reflect the action and enters the "Log Before Action" sub-flowchart. This sub-flowchart adds a new row to the log list, assigns field values and fills in the "Before" rich text field with the log fields template. Subsequently, the user progresses its database action.
Prior to finalizing the action, the system incorporates the "Log After Action" sub-flowchart. Within this sub-flowchart, it integrates the after-action template into the rich text field and ensures simultaneous saving of both the user's loggable action and associated log items. This synchronized approach guarantees preservation of logged data upon action commitment.
Log items should always be saved in UTC, you can display timestamps in local time for user convenience but it should be stored in UTC format. This practice ensures consistency and accuracy across different time zones
The first step is to make the Log data list, this will be the list used to record and save the changes made.
Change Log
Reference to changed item
Reference to signed in user
After Action Rich Text
Before Action Rich Text
Date and Time of change (UTC)
Log Action (Single-select)
Name of Changed Item
Name of User
Alternatively, the last two items can be derived using the references in the first two fields. Opting to save and utilize text-based name fields can enhance performance in the Log management screens and ensures the referenced person cannot change.
You will also need to make a concept in the concept tab of the resource pane, this concept describes logged actions. As an example this can be:
New Item
Edit of General information
Edit of Specific information
(soft) delete
Full delete
The flows handling the logging need a few transient fields to store some information used in the logging process.
Log Action (Single-select)
Reference to changing item
And a few transient field for searching the log list:
Name User (text)
Date Action (date time)
Log Action (multi-select)
To create the log template, first, add a reference component to the canvas. Within this reference component, incorporate a table with a column for the field names and a column for the corresponding values. If your application features multiple screens with varying editable fields, consider making templates for each screen, reflecting the specific fields available for modification. In this tutorial, we utilize one template for general information and another for all fields within the main data-list.
The properties of this table are default display mode, no column or row as header and no borders but this is up to the developer.
This solution is tested for 150+ fields and a repeater in one template without any issues.
This flow is very simple and will be the management screen of the logging system. The first step is resetting the Filters with a assignment node followed by the interaction node for the overview. Connected to the Log overview there is another interaction node for the log details page, here we show the log item details and see saved fields.
The details page shows some information about the log item with below it the rich text fields for the before and after situation. With these shown next to each other you can see changes immediately.
There are two flows that actually do the work, the before change log flow and the post change log flow. In the first flow a new row is created in the change log, the information fields are filled and the template is written to the before action rich text field.
In the second flow the details are checked, the time can be updated and the post change rich text field is filled with the template again but this time with the changed information. Optionally you can also end with a save node to commit the changes then and there and save the change log item at the same time, know that with the save node ALL changes are committed.
The Write template to rich text node has the above picture as template, these are templates for each possible action that can have different fields to be logged. In this example the top one is when somebody edits a screen with access to all fields in from the main list, with the second template only for when a user edits the general info page. The transient field Log Action made earlier is used to check the conditionals and which choose the right template for the right screen. The same templates are used for the before and after flow.
In this section, we'll explore the practical implementation of the log entry flows discussed earlier into the core functionalities of your application. Specifically, we'll focus on how these flows are integrated into the junctures where changes are made to items within the main list that need to be logged.
It is important for this part to know your application and analyze it if the application is less known. Go trough every flow where a user can:
Create an item
Change an item
(soft) Delete an item
This can also be checked using the find usages on the data list AND its fields or going to the preview of the application and use go to flow from the debug menu on every save or delete button. The change log depends on doing this part completely so this is an import step to do properly.
When a log trigger moment is found you add an assignment node to set the Log action transient field immediately after the start node. The value of this field will depend on the action in the main so it cannot be part of the sub-flow creating the log. After the assignment node you add the sub flow Log before action flow and connect the sub-flow back into the main flow functionality. Before any changes are saved but after the interaction node you add the post change flow, then connect this flow the the save or end node.
When all steps are finished the result can look like this:
Logging Multiple Lists: Expand the logging system to handle changes from multiple lists. Implement a mechanism to differentiate changes from different lists and ensure that the appropriate template is applied to the log entry's rich text field. Add a reference field to the log items for each list and keep track of which list you are changing before entering the make log flows.
Data Retention Policy: Consider establishing a data retention policy to manage the duration for which log items are retained. Develop a cleanup process that runs periodically, based on either a set number of years or a specified number of items, to prevent database overload and maintain storage efficiency.
File Management: Avoid storing files directly within log items to mitigate storage space usage and potential performance impacts. Implement a file management system that links files to log entries without duplicating them, thereby minimizing storage requirements and optimizing processing time.
Performance Optimization: Keep the log flows concise and efficient to avoid performance degradation. Be mindful of the complexity and extent of the log flows, ensuring they do not excessively impact system performance.
