This article explains known limitations and behaviors when syncing Filevine (FV) data into the Data Warehouse (DW). It’s designed for users who need a practical understanding of what works, what doesn’t, and why some data might seem inconsistent or delayed.
Schema Management
Schema = the structure of your data table (columns, fields, etc.).
- Template changes aren’t tracked
If someone updates a project template in Filevine’s UI, Filevine does not send any event to let us know. The Data Warehouse won’t notice changes unless other data updates happen. - New fields and sections aren’t added immediately
New Form or Collection fields/sections won’t show up in the DW until Filevine sends a webhook event using them. No event = no column in the DW. - Null values might not show up
In some cases, Filevine doesn’t include empty (null) fields in API responses. That means those fields may be missing from DW unless updated later. - Inconsistent data between endpoints
Filevine often returns different data in the LIST view (many items) vs. the ITEM view (one item). Our system uses both, which can cause inconsistencies. - Obsolete or deleted fields
- If a field is removed in Filevine, it stays in the DW.
- Obsolete fields don’t appear in the API, so the DW only learns about them the first time data is received.
- The field type (text, number, etc.) is guessed from the first data received.
Known Missing Webhooks
Sometimes, actions in the Filevine UI don’t trigger a webhook, even though they should. When this happens, our system won’t know the data changed, resulting in no update recorded in DW.
For more detail on which objects are affected, read the article: Filevine Object Support and Limitations in Data Warehouse
LIST vs ITEM Endpoints
We use two types of Filevine API endpoints:
- LIST endpoints (used for hydration and syncs): Return many items, but often less detail.
- ITEM endpoints (used for webhooks): Return full detail, but only one item at a time.
Some fields only appear in one or the other, which may lead to mismatched data between hydration and real-time events.
Taskflow Data Handling
Taskflows are automated actions in Forms or Collections.
- No separate table
Taskflow data is saved inside the Form or CollectionItem table. - Event-only updates
Taskflows only update in DW via webhooks, not hydration. - Webhooks may fail
Filevine sometimes fails to send these webhooks — it’s unpredictable. - No user or time info
Filevine doesn’t provide who/when the taskflow ran. We can only log the webhook’s timestamp. - Types of Taskflow events
- Executed: “Adds _executedAt” and “_executedBy columns.
- Reset: Adds _resetAt and _resetBy columns.
- Only one of these sets will ever be filled per row.
For example: If a taskflow is reset after being executed, the executed fields will be overwritten by reset data.
- Doesn’t trigger hydration
Executing or resetting a taskflow doesn’t mark the project as updated. So, nightly syncs may skip it.
Rehydration Behavior
Rehydration is a scheduled refresh of your DW data.
- The current table is updated with the latest snapshot.
- The historical table keeps all old and new records — nothing gets deleted.
Audit Support
Audits track changes to your data over time.
- We support Audit by IDs in some tables. If a table doesn’t support this, it also won’t support audit by values.
Check which tables are supported by audit in the next article: Filevine Object Support and Limitations in Data Warehouse
Field Support Overview
Here’s how common fields are supported in the DW:
| Field Name | Populated By | Notes |
| webhookEvent | Webhook | Type of event (Create, Update, etc.) |
| webhookTimestamp | Webhook | When the event was received |
| webhookUserId | Webhook | Who triggered the event (if available) |
| dwCreatedAt | DW System | First time the row appeared |
| dwUpdatedAt | DW System | Last time this row was updated — only in current schema, not historic |
| All other fields | Webhook / API / Logic | Populated based on event data or sync logic |