Logging archiving and maintenance

Logging, Archiving & Maintenance

When designing your data model and application processes, it is your responsibility as the developer to decide where and how logging or auditing should be implemented. WEM does not automatically keep historical records of user actions or data changes, so you must explicitly create the structures and logic needed to capture them.

A example implementation of a change log can be found here: Making a Change Log

Logging, Auditing & Traceability

What to Log

It is important to think about what you want to log and why certain information should or should not be logged, this should be discussed before you start building logging functionality. This goes for both which lists to log and what actions to log. Do you want to log every action or only specific actions, when something is logged what information can i safely log and what should not be persistent information. Logging can have detrimental impact on performance and should only be done with a reason.

Some examples:

• User login and logout

• Record creation, update, and deletion

• Changes to critical fields (e.g., status, assignment, approval)

• Import or batch processing results

• API calls or external system interactions

Basic Logging Fields

Use a dedicated Logging list with fields such as:

• User

• Date-Time

• Event type (created, updated, deleted, login, error, etc.)

• Description/details

• Optional: reference to the affected record (using REF_)

  • Keep in mind that this reference becomes unknown if the referenced record can be deleted.

When to Avoid Logging

Some situations can lead to unnecessary logs:

• Fields changing with a high-frequency

• UI-only interactions

• No specific reasons to keep the data

Define a threshold to keep logs meaningful rather than noisy.

Log Retention & Cleanup

Every logging strategy requires a clear decision on how long log entries should be kept. Logs grow quickly and especially for high-volume activities such as API calls, automated imports, or system events they can significantly increase database size and degrade performance. Determine in advance which logs are short-lived operational data (e.g., API request logs that should be purged daily or weekly) and which logs serve long-term auditing or compliance needs. Implement regular cleanup logic for short-term logs to prevent unnecessary growth, and store long-term audit trails in a dedicated, optimised structure.

Archiving & Deletion Strategy

Soft vs Hard Deletion

Datalists should use soft deletion to avoid losing important data and to maintain relational integrity on lists with references. This keeps the references alive and makes sure the data is not lost.

Soft deletion pattern:

• Boolean field IsDeleted

• Optional: DeletedOn, DeletedBy

• Filters ensure deleted records are never shown in standard views

Hard Delete Should Be Used When…

• The data is purely temporary and has no long-term business value.

• High-volume data (such as API logs or import buffers) would grow too large if kept.

• GDPR or privacy requirements demand full removal of personal data with no trace.

• Keeping the data introduces unnecessary risk, cost, or performance overhead.

Archive Lists

For specific business domains, it can be useful to move old records into “Archive” versions of lists:

Examples:

• Completed projects older than 5 years

• Inactive employees

• Process logs past retention limits

Archive lists reduce clutter and improve performance in high-volume applications.

Maintaining a Clean Data model

Removing or Marking Obsolete Fields

When fields become unused:

• Prefix with OLD_ or XXX_

• Update technical names

• Remove references in templates and flows

• Delete once validated

This prevents accidental use of outdated fields.