Transactions

Transactions in DataGuard CPM are the core mechanism through which changes to a Citizen's Permissions and Consent Purposes are recorded and tracked. They provide an essential audit trail that ensures transparency, accountability, and compliance with data protection regulations.

What Are Transactions?

Transactions represent the audit trail of any changes a Citizen makes to their Permissions (Consent Purposes). Every time a change is made—whether a Citizen grants or withdraws consent—a Transaction is created. This record is immutable, meaning it cannot be edited once created. However, it can be reverted by creating a "reversion transaction" (see "Revsion Transactions" section).

Fields in a Transaction

Each Transaction consists of several fields that capture detailed information about the changes:

• externalRef: The unique reference associated with the Citizen. This ties the Transaction to a specific individual within the system.
• recordedAt: The timestamp when the Transaction was created. This is automatically set by the service and represents when the change was officially logged.
• obtainedAt: This indicates when the consent was originally collected. It can be manually defined or will default to the recordedAt time. The obtainedAt date is critical in determining which permission change is currently active—permissions with the latest obtainedAt date take precedence.
• privacyPolicyRef: The reference to the privacy policy that was active at the time of consent.
• permissionStatementRef: The reference to the permission statement used when the Citizen consented. This ties the Transaction to the specific language or terms that were presented to the Citizen.
• changes: A list of the specific Consent Purpose changes recorded in the Transaction. These changes will eventually be reflected in the Citizen's Permissions.

Change Object Details

Each entry in the changes list includes the following fields:

• optionId: The id of the Consent Purpose that has been changed.
• state: The new state of the Consent Purpose, such as "granted", "denied", etc.
• justification: The lawful basis used for the change, such as "consent" or "legitimate-interest."
• obtainedAt: An override for the obtainedAt date defined on the Transaction. This allows for specific timing adjustments for individual changes.
• validFrom: This can be used to set a future date when the consent will take effect. The change will only be considered active once the validFrom date has passed.
• validUntil: Defines the expiry date of the opt-in or opt-out. If no validUntil is specified and if the Consent Purpose has a default expiry period, the system will calculate it based on the default expiry.

Audit Fields

Transactions also include several fields specifically for auditing purposes, which help track the source and context of the change:

• sourceSystem.reference and sourceSystem.name: These fields track which system the Transaction originated from, helping to identify the source of the change. Both fields accept arbitrary strings.
• source: This field can be used to record additional information about what triggered the Transaction. This information is displayed in the UI and is also an arbitrary string.
• notes: Free-text notes can be added to the audit trail for additional context. These notes are shown in the UI but are not passed downstream to Permissions.
• delegatedAuthorityId and delegatedAuthorityName: These fields capture the id and name of the delegate who authorised the Permission change, providing further clarity on who was responsible for the action.

Reversion Transactions

If a change needs to be undone, a reversion transaction can be created. Instead of supplying the usual transaction fields, you provide the revertedTransactionId of the original transaction you wish to revert, along with a "reason" explaining why the reversion is necessary. This ensures that even reversals are fully tracked and auditable.

Accessing Transactions

All Transactions are accessible via both the API and the UI.