Understanding Row Locks During Sync

Summary

Row locks are a normal part of how Salesforce protects data integrity during updates. When many processes (including Riva) are updating related records at the same time, it is expected that some updates will temporarily encounter a row lock (UNABLE_TO_LOCK_ROW). These errors are raised by Salesforce, not Riva, and are a standard concurrency mechanism rather than a sign of data corruption. In most cases, they result in temporary failures that are retried and eventually succeed. The practical goal is to monitor their impact, reduce unnecessary contention where possible, and investigate only when they cause persistent sync or performance issues.

What is a row lock?

A row lock occurs when Salesforce temporarily obtains exclusive access to a record, and sometimes related records, while a DML operation is in progress. During this time, the client holding the lock can modify the record, and other clients can still query it, but they cannot update or lock it.

If another client attempts to update or lock the same record before the lock is released, Salesforce waits for a short period, typically about 10 seconds. If the lock is still unavailable, Salesforce throws a DmlException or QueryException with UNABLE_TO_LOCK_ROW. This is commonly referred to as a row lock timeout error.

This behavior is intentional. Salesforce uses row locking to prevent conflicting writes and maintain data consistency.

Why row locks happen during sync

During sync, Riva commonly updates Salesforce Event records, EventRelation records, and related objects such as Account and Contact through relationships like WhatId and WhoId.

Salesforce may lock not only the record being updated, but also records related to it. For example:

• Updating an Event can lock the Event itself and related Contact or Account records.
• Updating EventRelation records can lock the underlying Contact or other related records.

Row lock timeout errors are more likely when:

• Many events are related to the same Account or Contact.
• Many Events are related to the same Account or Contact (large number of child Contact records exist under the same Account).
• Large attendee lists generate many EventRelation records for the same event.
• Multiple users or sync cycles update the same Event or EventRelation records close together in time.
• Salesforce triggers, flows, or other automation run on Event, EventRelation, Account, or Contact records at the same time Riva is updating them. 

In this context, row lock errors are a concurrency issue. They are caused by overlapping operations that attempt to update the same Salesforce records, or related records, at the same time.

When row locks are expected

Row locks are more likely and generally expected in high-activity Salesforce environments where:

• Many users are syncing concurrently.
• Events have large attendee lists.
• Accounts have many child Contact records.
• Custom triggers, flows, or other automation run when Event or related records are updated.

In these scenarios, multiple operations may attempt to update the same records, or related Salesforce records, at nearly the same time, increasing the chance of row lock timeout errors.

Are row locks harmful?

By themselves, row locks are not necessarily harmful. They are a standard Salesforce mechanism used to enforce exclusive access to records and prevent conflicting updates.

Riva has built-in handling to manage these errors so that appointments and related records can still be updated. In many cases, a row lock error in one sync cycle is followed by a successful update in a later cycle after the lock has cleared.

The main practical impact is usually one of these:

• Temporary sync failures for specific records during a sync cycle.
• Retries and slight delays before the update succeeds.
• Possible performance concerns if the volume of row lock errors becomes very high.

That is why row locks are often treated as something to manage and reduce, rather than something that must always be fully eliminated.

Why some row locks are just “the nature of the game”

Salesforce prioritizes data consistency by locking records during updates. In a sync scenario involving many concurrent users, large attendee lists, heavily related data, and custom Salesforce automation, some lock contention is unavoidable.

Row locks are more likely when the environment includes:

• Many users syncing at the same time.
• Events with large attendee lists.
• Highly related data, such as Account records with many child Contact records.
• Custom triggers, flows, or other automation that run during Event or related record updates.

Testing referenced in the tickets supports this pattern:

• In a standard Salesforce org, bulk processing many appointments with many attendees produced relatively few row locks.
• In a customized org with additional triggers and many Contact records, row locks increased as the number of attendees increased.
• Disabling a custom Event trigger significantly reduced row lock errors.

This suggests that row lock behavior is often the cost of performing large-scale, parallel synchronization safely in a customized Salesforce environment. It is not necessarily a sign that the sync process is broken, but it may indicate that the environment needs tuning if the lock volume becomes high.

When to investigate further

Although row locks are often expected in busy Salesforce environments, they should be investigated more closely when they are associated with:

• Persistent sync failures for specific records.
• Noticeable user-facing errors or missing updates.
• Significant performance degradation or sync delays.
• Large or sudden spikes reported by Salesforce, such as tens of thousands of row lock errors for the Riva integration user over a short period.
• Recent changes to Salesforce triggers, flows, batch jobs, or other automation that coincide with new row lock patterns.

In these cases, typical investigation steps include:

• Reviewing Salesforce automation on Event, EventRelation, Account, and Contact records.
• Considering configuration options that may reduce contention, such as limiting which Account records events are related to, reducing concurrent sync threads, or adjusting attendee handling.
• Reviewing logs to identify frequency, patterns, affected users, and affected Salesforce objects.

The goal is to determine whether row locks are causing business impact. The focus is not on eliminating every row lock event, but on reducing lock contention where it causes sync failures, delays, or user-facing issues.