AuditTrails

Structure

We categorize the events into 3 CoreEntity types:

• Organization.
• Engagement.
• Operator.

Audit Trail events:

• CoreEntityChange: Property changes to the main entities (Organization, Operator, Engagement).
• ConfigChange: Configuration changes including:
  • Password Policy
  • SAML IdP Config
  • Operator Credential
  • Storage Location
• LicenceChange: Changes related to:
  • Engagement Application
  • Engagement Active status
  • Subscription ID changes
• OperatorAccessChange: Access-related changes including:
  • Operator Engagement Application Role
  • Operator Engagement
  • Operator Organization
• EngagementOrganizationChange: Changes to Engagement Organization relationships

Denormalization

Because operations often involve relationships between two core entities (Operator, Organization, Engagement), and these relationships may exist across different organizations (especially for Service Provider Organizations), the data is denormalized at both ends of the relationship. This enables direct auditing by each entity involved.

The logs include "ContractedEntity" and "ContractedEntityId" fields to support this.

Denormalization Examples

1. Operator-Organization Access Events Creates two records:

• CoreEntity: Operator → ContractedEntity: Organization
• CoreEntity: Organization → ContractedEntity: Operator

2. Organization-Engagement Trust Events Creates two records:

• CoreEntity: Engagement → ContractedEntity: Organization
• CoreEntity: Organization → ContractedEntity: Engagement

3. Operator-Engagement Access Events Creates two records:

• CoreEntity: Operator → ContractedEntity: Engagement
• CoreEntity: Engagement → ContractedEntity: Operator

Message Structure

Each audit record contains three message-related properties:

• LogMessageKey: Resource key for localization
• LogMessageParams: Parameters for message formatting
• LogMessage: Formatted message in English

This structure enables localization of audit messages in the UI while maintaining a consistent audit record.