The Product Idea boards have gotten an update to better integrate them within our Product team's idea cycle! However this update does have a few unique behaviors, if you have any questions about them check out our FAQ.

Alteryx Designer Desktop Ideas

Share your Designer Desktop product ideas - we're listening!
Submitting an Idea?

Be sure to review our Idea Submission Guidelines for more information!

Submission Guidelines

Allow Salesforce connector credentials to be passed between users when sharing workflows

We aren't getting a huge amount of help from support on this, so I'm posting this idea to raise awareness for the product teams responsible for the Salesforce connectors and the embedded Python environment.

 

This post from user Dubya describes the issue in detail:

 

I have a workflow with several salesforce tools in it, which works fine on my machine. But we need another alteryx user in our office to be able to access, run and maintain the workflow too, via their machine and copy of alteryx designer.

However we're finding that the salesforce inputs and outputs can only be authenticated on one machine at a time.

When the other new user opens the original workflow from the shared network location, the salesforce tools display an error "Salesforce Input (1): {'error': 'invalid_grant', 'error_description': 'authentication failure'}" and the tools fail to load any data. But we can see the full query in the tool and we can even set the custom query option and validate the query successfully, which suggests the source is being correctly connected to and queried, but we just cant run the tool.

The only way to run the tool successfully is to change the credentials and re-authenticate the tool. However this then de-authenticates the original machine, and when we open up the workflow on there and try to run ying the workflow brings back the same error.

We've both tried this authentication back and forth on our own machines and each time one of us re-authenticates, it de-authenticates the other, leading to it triggering the error.

Can someone help explain what's going on and how to fix it, as this doesn't bode well for our collaboration.

We're both running:
The latest build of version of designer 2021.2 (original machine also running desktop automation)
Salesforce Input Tool v4.1.0
Salesforce Output Tool v1.3.0

My response here identifies that this is a problem for our organization as well:

 

We're experiencing the same issue. It appears to be related to how the tool handles password and security token decryption. I've found that when you modify the related registry entry from "true" to "false", you can see in the tool's xml that the encrypted password and security token are still in there. I'm not sure what else is going on behind the scenes beyond that, but that ought to be addressable by the product teams handling the Salesforce connectors and the Python installation embedded in Designer.

The only differences in our environment compared to u/Dubya's are that we're running on 2020.4 and attempting to use Salesforce Input Tool v4.2.4.

 

This is a must have for anyone who needs the ability to share workflows among multiple users. This is part of a series of problems that these updated connectors have been plagued with since introducing them years ago, and no one at Alteryx seems to care enough to truly fix the problems. Salesforce is a core system for our organization, so having tools that utilize the latest version of Salesforce's APIs is very important to us. The additional features that the Input tool provides are welcome, but these bugs have to be sorted out in order for us to extract any kind of value out of them. If the "deprecated" Salesforce tools were ever to be removed from Designer while there are issues with the "new" connectors, we would have no choice other than to never upgrade Designer/Server again and be forced to look for another product to serve as our ETL platform.

 

Please, please, please address this.

6 Comments
jschueller
6 - Meteoroid

More information that we've found on the root issue (which is fixed when publishing a workflow to a private Gallery, but not fixed when downloading said workflow to a different machine than the one that originally published it).

 

error while saving workflow in Gallery: RuntimeError: Internal Error: DecryptPassword - 

 

Salesforce input tool "buffer too small" 

 

Furthermore, I'd like to stress another big reason we want to be using the updated toolset: Salesforce API versioning. The specific version that is baked into the "deprecated" toolset is due to be sunset by Salesforce sometime in the next year.

AlteryxCommunityTeam
Alteryx Community Team
Alteryx Community Team
Status changed to: Accepting Votes
 
CatheyH
8 - Asteroid

Having just upgraded to 2021.4 and implementing new connectors this is causing me a significant headache. 

I edit larger workflows on my laptop and the run them on the server which has better connectivity and less likely to fall over when the VPN breaks. We use a service account in the credentials for exactly this reason - any of the team may need to open the workflow from the shared area and edit it.

In addition the query is being "lost" when new credentials are entered. I have seen the workaround using the XML, but this isn't ideal either.

Please fix!

CatheyH
8 - Asteroid

Just an addendum to the note above. After some testing, using the newer Salesforce connectors seems to be completely unworkable for us now. We are going to have to go back to deprecated tools but will need a solution by summer when the APIs will no longer be available

jessarthur
7 - Meteor

I'm running into the same issue. Has anyone tried switching to the SF ODBC connection instead of the connector tools? Any success?

jschueller
6 - Meteoroid

@jessarthur We've been using the ODBC driver for a while now. It works well. Note that it only supports exporting data - you'll need to continue to use the Salesforce Output connector to modify data in Salesforce. I haven't experienced issues with the Output connector so much as the Input connector, so I'd say that trying out the ODBC driver is worth the time if you haven't done so already.