Editorial illustration.
Originally published 26 June 2023; rewritten and reviewed on 15 October 2026.
Two related records need changing together. If the first succeeds and the second fails, the CMS is left with a state the editor never intended. That is the problem a transaction should solve; wrapping every line in a transaction without identifying that boundary does not make the process clearer.
Define what must succeed together
List the database changes that form one business operation. Keep the scope short enough to avoid holding locks while waiting on a remote API or an email service.
For legacy Xperience versions exposing CMSTransactionScope, the conceptual structure is:
using CMS.DataEngine;
using (var scope = new CMSTransactionScope())
{
// Perform the related writes using the installed version's APIs.
// Let failures propagate so the operation is not reported as successful.
scope.Commit();
}
The Xperience 13 API reference documents Commit and disposal. The original post mixed several transaction mechanisms and named a rollback method that should not be assumed to exist. Use one supported approach for the version in the project.
Keep failure visible
Handle the exception at a boundary that can log an appropriate diagnostic and return a failure result. Catching an exception inside the operation and continuing to report success defeats the purpose of protecting related writes.
An email or third-party API request is not automatically undone by a database rollback. Where such work follows the transaction, arrange a retryable handover, such as a persisted outbox, if the application requires dependable delivery.
Test partial failure deliberately
Make the second write fail in a test environment and inspect both records afterwards. Then test a successful run and a repeated request. A transaction protects a defined set of changes; the surrounding workflow still needs authorisation, idempotency and a clear result for the caller.