Hi @Gowtham ,
A common ODC approach is to create a reusable Audit Service application that exposes a single Service action (e.g., CreateAuditLog) that all applications call whenever important business events occur, such as Create, Update, Delete, approvals, or status changes. Store details like Entity Name, Record ID, Action Type, User, Timestamp, and optionally old/new values (as JSON) in a centralized audit entity. Keep audit records append-only; avoid logging sensitive information such as passwords or tokens.

Regards
Abhijith

Hi @ABHIJITH G ,

I do have a doubt.

One limitation in ODC is that Libraries cannot contain transactional entities, so they cannot be used to centrally store audit records. While a Library can provide reusable logic, it cannot host the audit data itself.

To implement a centralized audit repository, we would need a Service application that contains the audit entities. Since entities are exposed read-only in ODC, applications would invoke exposed Service Actions to create audit entries and persist them in the centralized audit entities.

Regards,

Adeeb Alam

Hi Gowtham,

Although there isn't currently a dedicated ODC Forge component for audit logging, you can refer to existing OutSystems audit logging implementations and use them as a reference when building your own solution in ODC.

For example, the Audit System Console component can provide some ideas around the audit data structure and logging approach:

https://www.outsystems.com/forge/component-overview/15186/audit-system-console-react-o11

In ODC, a common approach would be to create a centralized Service that stores audit records and expose Service Actions that applications can invoke whenever important business events occur (Create, Update, Delete, Status Change, Approval, etc.). The Service can maintain the audit entities while consuming applications simply call the exposed actions to create audit entries.

Thanks,
Adeeb Alam

Hello @Gowtham,

For ODC, I generally recommend building your own Audit module rather than relying on Forge components.

Recommended Architecture

Entity: AuditLog

| Attribute     | Type       |

| ------------- | ---------- |

| Id            | Identifier |

| Timestamp     | DateTime   |

| UserId        | Text       |

| UserName      | Text       |

| EventType     | Text       |

| EntityName    | Text       |

| RecordId      | Text       |

| Action        | Text       |

| OldValue      | Long Text  |

| NewValue      | Long Text  |

| ScreenName    | Text       |

| CorrelationId | Text       |

| Remarks       | Long Text  |

Store Before/After Images

Instead of individual fields:

OldValue = JSONSerialize(OldRecord)

NewValue = JSONSerialize(NewRecord)

Avoid Logging

❌ Passwords

❌ Tokens

❌ Sensitive secrets

❌ Large binary files

Pattern I Recommend Most

Common Audit Module

        ↓

Public WriteAudit Action

        ↓

JSON before/after snapshot

        ↓

AuditLog Entity

        ↓

Background Timer

        ↓

Retention & Reporting