Configure delete event logging

Level: advanced

note

This functionality is available for Creatio 8.3.2 and later.

Some integrations with Creatio are designed to exchange data and support scenarios where network connectivity is temporarily unavailable or limited. Typical examples include mobile apps and external systems that maintain local data caches. Such integrations synchronize created, updated, and deleted data when a connection to Creatio becomes available.

Handling record deletions requires a separate approach in offline and cache-based integrations. While an integration is offline, records can be deleted in Creatio. After the integration reconnects, it needs a way to determine which records were deleted in order to keep local data consistent.

If deleted records are not identified:

• deleted records remain in local storage
• users continue working with obsolete data
• changes made to deleted records can be sent back to Creatio
• deleted records can be unintentionally recreated

To avoid these issues, integrations need a way to detect deleted records for every object involved in synchronization. Otherwise, the integration reloads previously synchronized data and verifies the existence of each record in Creatio.

This approach does not scale for large datasets. Reloading and verifying large volumes of data increases synchronization time, system load, and network traffic.

Since version 8.3.2, Creatio provides a dedicated REST API that configures delete event logging for selected objects and exposes delete event logs to external systems for incremental synchronization.

Delete event logging provides the following capabilities:

• Log delete events for selected objects based on explicit configuration.
• Configure which objects are tracked per consuming app.
• Support both manual and automatic configuration of tracked objects.
• Retrieve delete event logs through an API with a minimal and stable contract.
• Filter delete event logs by object, period, and app code to support incremental synchronization.
• Paginate API responses to handle large data volumes and ensure predictable memory usage.
• Apply a configurable retention policy to remove outdated delete log records automatically.
• Enforce access control based on operation permissions.

Add objects for delete event logging

To use the API to add objects to delete event logging, ensure that:

• EnableEntityDeleteEventLogging additional feature is enabled. Instructions: Manage the status of an additional feature. When the feature is enabled:

  • new delete events are logged for all objects and apps that are added and marked as active in the Entity delete event log configuration lookup. Learn more: Add objects manually.
  • existing and newly created delete log records remain available through the API until they are removed by the "Clear entity delete event log" business process. Learn more: Remove outdated delete log records.

  Otherwise, new delete events are not logged and existing delete log records remain available through the API until they are removed by the retention business process.

• the user on whose behalf to add objects for delete event logging has permission to the "Can View Entity Delete Log" (CanViewEntityDeleteLog code) system operation. Out of the box, only users that have the "Administrator," "Developer," "System administrators" role can add objects for delete event logging. Learn more: System operation permissions (user documentation).

Select how to add objects for delete event logging based on the business goals listed in the table below.

Business goal	Configuration option	Use cases
Configure delete event logging for a predefined and stable list of objects	Manual configuration (UI)	The list of tracked objects is predefined and changes rarely Configuration is managed by administrators Delete event logging is configured once and maintained manually
Configure delete event logging dynamically as part of app setup or deployment for mobile apps, integration apps, or installed functionality	Automatic configuration (API)	The list of tracked objects depends on the app state, installed functionality, or environment Configuration must be performed programmatically Delete event logging is configured during CI/CD pipelines or scripted environment setup Apps must configure delete event logging automatically on first run

Both configuration options use the same underlying storage, validation, and caching mechanisms and can be safely used together. Delete event logging operates independently of other change-tracking mechanisms. Configuration changes take effect immediately and do not require restarting the instance or triggering compilation.

Add objects manually

1. Click in the top right → System setup → Lookups.

2. Open the Entity delete event log configuration lookup. Out of the box, the lookup is empty.

3. Click New.

4. Fill out the properties of the lookup value. Out of the box, the lookup includes columns listed in the table below.

   Property	Description
   Consumer application code	An arbitrary name of the external system that consumes delete event information. For example, "IntegrationService."
   Entity schema	Select the object for which record deletions are logged. For example, "Contact."
   Description	An arbitrary description that can be used to document the purpose, owner, or deployment context of the configuration.
   Active	The checkbox that determines whether to enable delete event logging for specified values of the Consumer application code and Entity schema properties. Out of the box, the checkbox is selected. When the checkbox is cleared, new delete events for the specified Consumer application code and Entity schema are no longer logged. Existing delete log records remain available until they are cleaned up by the "Clear entity delete event log" business process. Learn more: Remove outdated delete log records.

5. Click .

Add objects automatically

When you add objects automatically, apps register objects for delete event logging programmatically using a REST API. Learn more: Endpoints for managing delete event logs.

Automatic configuration does not introduce additional overhead during normal operations.

The configuration API is idempotent:

• adding an already active configuration for the same app code and object does not create duplicate records
• if a configuration exists but is inactive, calling the API reactivates it instead of creating a new record.

View list of logged delete events

When a record is deleted in an object that is added for delete event logging, Creatio writes a non-editable record of the "Entity delete event log" (SysEntityDeleteEventLog code) object. Creatio logs only the minimal metadata required to identify deleted records.

To view the list of delete events:

1. Click in the top right → System setup → Lookups.

2. Create a new lookup.

   1. Click New lookup.

   2. Fill out the lookup properties.

      Property	Property value
      Name	Entity delete event log
      Object	Entity delete event log

   3. Click Save.

3. Open the Entity delete event log lookup. Out of the box, lookup includes columns listed in the table below.

   Column	Description
   Operation date UTC	The timestamp of the delete operation, in UTC.
   Entity schema name	The title of the object where the deletion occurred. For example, "Contact."

4. Set up the lookup list.

   1. Click View → Select fields to display on the lookup toolbar.

   2. Click → select the "Record id" column → Select.

      Column	Description
      Record id	The column includes the unique ID of the deleted record.

   3. Click Save.

Delete event creation is optimized to minimize performance impact:

• the decision whether to log a delete event is based on in-memory cached configuration
• writing a delete event is event-based and does not introduce noticeable delay to the delete operation.

Remove outdated delete log records

Delete event logging supports automatic cleanup of outdated delete log records to prevent uncontrolled growth of the delete event log. Retention behavior is managed by the "Entity Delete Event Log Expiration Period" (EntityDeleteEventLogExpirationPeriod code) system setting. This system setting defines the number of days delete log records are stored. Out of the box, "180." Delete events older than the specified value are removed automatically by the "Clear entity delete event log" business process.

The system setting value affects only which delete events are returned by the API. The API returns delete events that are within the configured retention period.

Follow the system setting value when implementing integrations, since the maximum interval between successful synchronizations must be shorter than the retention period. Otherwise, some delete events can be permanently lost. For example, long offline periods, such as mobile devices that remain inactive for several months, can require full data resynchronization instead of relying only on delete event logs.

---

See also

Manage an existing additional feature

System operation permissions (user documentation)

Endpoints for managing delete event logs