"Workflow Status" column not always gets updated in the SQL table

You may encounter cases where "Workflow Status" column in a SharePoint list display a certain value, e.g. "In Progress", but the corresponding numeric value exported by SQList in the SQL table does correspond to the status in the list. Furthermore, you may find that this inconsistency seems to happen at random.

The reason is that SQList uses the Modified column to detect changes to a list item, which is updated every time an item is updated. The workflow status column instead, is updated by a separate process that kicks in after the item is saved, and while the status column is updated, the Modified column is not.

If SQList reads the item before the workflow has completes, it will export the status as is was before the workflow completed; if it reads if after, it will export the updated valued. In the formed scenario, unfortunately is it not possible for SQList to detect the new status value as the Modified date/time has not changed.

That explains the apparent randomness of this issue. See the screenshot below of an item retrieved twice and displaying the same Modified value but two different status values.

Note that from ver. 4.0, SQList no longer uses the Modified column to detect changes, but the native tracking system in SharePoint but we have not confirmed yet whether that resolve this issue.

Note that this issue applies to all columns that are updated asynchronously and do not update the Modified date/time.

A possible workaround¹ could be to force an update of the Item, without changing any values, at the end of the workflow so that the Modified column is updated (note: ensure that the forced update does not kick off the workflow again, resulting in an endless loop).