Skip to main content

Community

I don't see any table which provides audit_log details for Kustomer Connector

Planned

Please sign in to leave a comment.

Comments

3 comments

  • Official comment

    Hi Abhijeet,

    Thanks for raising this. We'll pick it up as part of our near-term roadmap.

    One quick follow-up: "activity" in the audit_log table could mean a lot of different things (logins, config changes, data access, admin actions, etc.), so it'd help to get more specific. Could you share what sort of activity you have in mind, and how you're planning to use this downstream? or is OM_SUB_STATUS field change the primary usecase ? Understanding the use case will help us prioritize it correctly and build it in a way that actually fits your needs.

    Best,
    Vicky 
    Fivetran product team 

    Business impact: The audit_log is a key part of the Kustomer data footprint, as it provides the traceability needed to understand and validate activity across the platform. Since Fivetran is already ingesting multiple Kustomer entities, enabling this data would help maintain a more complete source-of-truth for downstream analytics, reporting, and audit use cases. Given the potential impact of this gap on data completeness and future use cases, it would be valuable to prioritize this request.

    Hi Vignesh,

    We would need the complete activity data available at the source level. 

    One suggestion would be to logically split the response into multiple destination tables rather than putting everything into a single table. For example, separate tables for:

    • Status change logs

    • Tag change logs

    • Custom attribute change logs

    • Other relevant activity/event types

    We are already using this data to derive information such as satisfactionLevel, answers, updates, etc. However, the current solution is not very reliable, and the requirement below is quite urgent and high priority.

    Having everything in a single table could also become difficult to maintain and query, particularly given the size and complexity of individual records. I'll leave the detailed table design and structure to your discretion, based on what would work best from the source data.

    Current high-priority requirement

    We urgently need the ability to track all changes and their corresponding timestamps for a set of custom fields under OM_SUB_STATUS.

    OM_SUB_STATUS contains several fields, including:

    • custom_l_2_non_fraud_outcome_uk_om_str

    • custom_l_2_fraud_outcome_uk_om_str

    • Other similar L1/L2 attributes

     track changes made to:

    • UK-OM-L2-NON-FRAUD-Investigation

    • UK-OM-L2-NON-FRAUD-Outcome

    The key requirement is to capture what the value was, what it changed to, and the timestamp of each change, so that we can reconstruct the complete change history.

    I'm unable to attach the Kustomer screenshot here, but I can share the relevant example/details separately if needed.

    Thanks!