WorkflowFirst updates records on a field-level basis, and tracks changes to a form so only the fields that are touched by the user are updated in the form. This allows multiple people to be editing a form simultaneously while reducing the risk of data loss or contention.

In WorkflowFirst every operation runs in the context of a transaction. Any errors that occur during that transaction will ensure that the entire transaction is rolled-back and no changes are committed to the database. This also applies to updating the search index and to sending any real-time notifications.

While the transaction is in progress, ordinarily all affected records will be locked by the database. Row-level locking is applied (instead of the more typical page-based locking), but this can be overridden when updating records with scripting (using the "locks off" keyword).

Alternatively, as discussed later in this section, you can enable Snapshot Isolation on the database to reduce locking considerably. Because WorkflowFirst is multi-threaded and multi-user, it's possible that two users or scripts that are running in parallel may cause something called a "deadlock situation" to occur. This occurs when two separate processes are dependent on each others' records, causing them to hang for each other indefinitely. 

Luckily WorkflowFirst has special support for detecting a deadlock situation and will take necessary remedial action. To do this it will automatically pause and retry one of the transactions, releasing the locks and allowing the other to proceed. It will then retry the transaction a second time after a random amount of time (under 2 seconds). If the deadlock situation repeats more than 50 times the operation will fail and an error will be displayed. Usually the user will not notice this happening, other than the action taking a little longer to commit. 

There are things you can do to reduce the likelihood of deadlocks occurring, however: 

1. Reduce the number of (or eliminate) asynchronous events. When you add an event handler (script) in WorkflowFirst, you can specify how it's invoked - either as synchronous, asynchronous or on idle. Here we're talking about an asynchronous event, which runs in the background after the transaction is committed. Because these launch on separate threads, the probability of multiple operations running in parallel increases, and this increases the likelihood that they will be competing to lock the same records. Usually it's unnecessary to make events run asynchronously.

2. Reduce the amount of time spent in script. Optimize your event handling code to ensure that it runs as fast as possible. Avoid looping through lots of records unless necessary.

3. If using SQL Server, make sure that the OfficeSuite Launcher (or other hosting application such as IIS) has optimal access to the SQL Server database. If possible, sit both the WorkflowFirst hosting application and the SQL Server database on the same machine so that database operations utilize the inter-process communication mechanism (IPC), rather than TCP/IP. The faster the application can access the database, the less time it will take and the less opportunity will exist for excessive lock retention and deadlocks.

4. If you are using Microsoft SQL Server, it's recommended that you switch on snapshot isolation . This is a relatively new locking strategy that uses row versioning instead of holding locks. Because each change creates a new version of the record, two transactions updating the same record will not conflict, and therefore it is not possible for a deadlock situation to occur. However this strategy does incur an overhead in terms of storage, and also a slight overhead in terms of update performance because of the additional time required to create the record version. It can also slightly impact query performance because specific versions of records need to be found in the query. A comprehensive study of the pros and cons of using snapshot isolation, and how to enable it, is beyond the scope of this document. More information should be sought from online Microsoft SQL Server resources.