I'm not sure if this qualifies as request or an issue but here it goes.

We've been synching data using the Genesys Connector for few months now. We're currently swapping the original Snowflake destination to an ADLS destination, more aligned with the overall architecture. So far so good.

In both cases however, we noticed the strange model proposed for the analytics_conversation_details_participant endpoint/table, this regardless of the destination. Custom attributes most likely handled as key-value pairs in Genesys are de-normalized into columns by the connector, which results in

1. Frequent schema changes, almost daily
2. Probably the sparsest table I've ever seen. Currently, the target table/files contain 708 columns, most of which being useless (ref. screenshot below). At some point, one will reach a limit.

Current workaround is to explictly ignore such columns but this leads to constant re-configuration and re-synch. Not viable. Obviously, we could reconfigure the connector to ignore all schema changes once and for all but this would prevent from benefiting of the flexibility offered by Fivetran, the Parquet file format and Snowflake's variant data type (downstream). It would defeat the purpose if you ask me. As a bare minimum, ignoring schema changes should be allowed for individual endpoint/table but this doesn't seem to be possible with the Genesys Connector. A better option would be to change the ERD and manage such custom attributes in their own table/files, pretty much as key-value pairs. Another approach could be to use struct type and variant type in Parquet and Snowflake respectively. Milage could vary with other destination types.

I understand that the Genesys Connector is lite. Nevertheless, I believe the handling of conversation participant custom attributes must be improved. Would Fivetran be willing to examine alternatives?

Thanks,

AL