Connector name: Iterable

Table name: User Current Profile

API documentation link:

Additional details:

1. A current-state USER table for the Iterable connector, or history mode as a per-table toggle. This is the real fix. Most downstream use cases want the current profile; those that want change history can opt in. As it stands, the connector's design forces every customer into the expensive option regardless of need.
2. Document the _FIVETRAN_ID derivation for USER_HISTORY. If it's a deterministic hash of a source field, customers could deselect the table and reconstruct the join key from their own data — the same pattern you already recommend for LIST_USER_HISTORY. Right now that recommendation isn't actionable for USER_HISTORY, because the join key is undocumented and depending on an internal implementation detail is not something I'm willing to build production models on without a written commitment.
3. Relative date values in row filters. Static-only means any date-based filter needs manual maintenance forever, which makes it unusable as a cost control.