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

Community

Please sign in to leave a comment.

Comments

9 comments

Date Votes
  • Official comment
    Sadie Martin Fivetranner
    • Edited

    Hi all,

    Appreciate your comments and upvotes here - we hear that this is an important addition to the Salesforce connector and have added it to the top of our backlog. To help us meet your expectations, can you share what data types would be acceptable to sync these columns in your destination?

    Best,

    Sadie

  • Sadie Martin Fivetranner
    • Edited

    Hi Matt,

    Sadie from the Product team here at Fivetran. Thanks for submitting this request. Can you share some more detail about the analytical value of these fields for you? We haven't received many requests like this, but understanding the use case will help us prioritize going forward.

    Best,

    Sadie

  • Harvey Hawks Jr User

    I have a similar request for the Attachment.Body field. I'm checking with our user for what the specific use case is.

  • Harvey Hawks Jr User

    Following up on my previous comment:

    I'm commenting here as I'm interested in a different field with the same base64 datatype.

    We have users who would like to archive Attachment data from Salesforce and store that unstructured data long-term in Snowflake (along with the rest of our SFDC data which is already being synced to Snowflake).

  • John Mills User
    • Edited

    We have similar requirements for document body/images from salesforce.  Clients want to use AI to do analysis of documents in snowflake.

  • Mihir Garimella User

    Same issue here - this is critical for our use case of extracting the text of ContentNote objects for LLM applications.

  • Sayan Chaudhry User

    +1 also facing the same issue, trying to ETL ContentNote to our data warehouse for some business analysis

  • Mihir Garimella User

    @Sadie we're ultimately looking to convert ContentNotes into text to feed into LLMs, so:

    • HTML string probably makes the most sense (and we can convert it to plain text on our end)
    • Base64-encoded HTML string is also fine, since we can easily decode it
    • Plain-text rendered string is also of course fine, but guessing that is less flexible for others' use cases 
  • Harvey Hawks Jr User

    FYI our users have developed an alternative and no longer need this feature.