In Alteryx, the Salesforce connector is very useful to easily import raw data from Salesforce using its wonderful API. All you need to input is the email and password for a API enabled user login, as well as the Security Token.
The connectors are so convenient to combine SFDC tables, that you will quickly have several within a single workflow, and you will most likely have several workflows, that you spent countless hours to configure, as Salesforce tables can be VERY long. For instance, you must select the proper combination of fields to extract, as Salesforce tables, especially the custom ones, are laden with open text fields, useless for analytics in most cases. Those open text fields are input with very few restrictions of characters and will often trip S3 or your database.
There is just a slight issue with this design: on one hand, the SFDC credentials you did input are stored locally in each connector object you deploy, on the other hand, most SFDC logins require episodic password changes as they are set to expire. And should that happen, you will have failing workflows, unless you tirelessly inventory the location of each and painstakingly process to edit them. In my experience, that is not the end of the suffering: when you click on the connector to go edit the credentials, Alteryx Designer sends a request to SFDC featuring credentials, and after a few of those requests, sometimes just a handful, SFDC will lock your login out! You will then need to either get an admin to unlock the account, always a fun conversation to have with an admin, or wait one hour for SFDC to automatically remove the lock.
I get to spend a lot of quality time with INDB tools, which represent 90% of my workflows. I love them, I can generate code almost at the speed of thoughts. They are fast to put together but also very powerful, especially when coupled with modern data bases such as Redshift or Snowflake, as they don’t hog any local resource.
Yet, I have been running over time into a series of issues and limitations of those tools, far from being obvious, and which all caused perplexity and time spent to address. I will share them through a blog series, and will start with a trap easy to describe, yet lethal in terms of its impact on data integrity: INDB Filter does not handle NULLs by default, unlike its cousin the In Memory Filter.
I skipped the Tableau conference last year as it was taking place in Vegas, and that is usually not a good experience, even without crowd shooters. I was happy to partake again this year to TC18, which took place in New Orleans.
The conference was well attended with 17,000 attendees, yet it never felt overcrowded like it does when in Vegas. The trade-off is that the NOLA Convention Center requires a lot of walking: I clocked 9 to 10 miles a day of walking. It gets a bit frustrating to walk from one end to the other end of the venue to attend a session, arrive on time and see it is already full, which happened to me a couple of times when the topic was APIs…
In my opinion, those APIs were elements of one of the two overarching themes of the Conference: Tableau is opening up for real and Tableau Prep is out of Beta. Both those themes reveal how pragmatic Tableau has become lately. For years, they were dismissing those customers needs and requests from the community: nah, Tableau does not need to open up, it is good as it is, and i f you need something else, you don’t understand visual analytics. Nah, Tableau does not need data to be prepped, and Alteryx success is such an epiphenomenon which has nothing to do with us. But eventually, witnessing the rise of usage of the web connector, and the IPO of Alteryx, they started seeing the light and responded. And I welcome that change! Continue reading
From a distance, editing field names might not seem such a big issue, worth dedicating a blog post. Yet, I realize how much experience I gained over time, dealing with such minor issues, which end up affecting my productivity significantly over time. In other words, consider each time you draft a new workflow in Alteryx, and you will realize that, whether you deal with long SFDC tables with __c names or other naming conventions that leave to be desired, you get to rename fields a lot. And you most likely have not had the best experience along the way. Read on as I will share some productivity tips and warn you about potential issues, especially in INDB.
If, when you use Tableau or Alteryx to query a Snowflake Database, you are getting weird $ amounts, not matching what is the database, you are experiencing a known bug in the recent versions of the Snowflake ODBC driver:
This is a big issue affecting floating number columns. Fortunately, it has been addressed with the release of ODBC Driver version 2.16.7 in August:
Make sure you update your ODBC driver as soon as possible!
Here are the instructions: