Skip to main content
Docs
Feature Requests Onboarding Trust Center Status Page

Community

Iterable User

Answered
Faina Burman User

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.

Please sign in to leave a comment.

Comments

1 comment

Date Votes
  • Official comment
    Abdul Ghaffar Fivetranner

    Hi Faina, Abdul from the Product team here. Apologies for the delayed response. 

    1. Current-state USER table: we've added this to our short term roadmap, I'll keep you updated on the progress. 
    2. _FIVETRAN_ID derivation: We don't recommend building production models on how _FIVETRAN_ID is calculated. It's an internal detail and can change. Once the current-state USER table is available, you shouldn't need to rebuild the key yourself.
    3. Relative dates in row filters: This is on our roadmap. I don't have a timeline to share yet, but I'll post here when I do.