Picture this: your company just got Alteryx Server. You are dazzled by the idea of scheduling your workflows and sharing your analytic apps. You publish your perfectly-working workflow, which utilizes an excel file hosted on a shared drive, to the server and – oh no!
If this has happened, it is likely for one of two reasons:
- You aren’t using the network, or UNC, path to the share.
- The workflow credentials, service or user account, being used to run your workflow does not have access to the share.
In this post, we will be focusing on the second of the two reasons. For more details on the first reason, head to the linked community page and check out solution #4.
This issue is often linked to access issues and Workflow Authentication. There are three ways that workflow authentication can be configured on Alteryx Server, and it will depend on your organization:
Require User Credentials – when running a workflow on Alteryx Server, a user will be prompted to enter the credentials of who the workflow should be run as.
Use Default Credentials– users will not be prompted and workflows will always be run as the Alteryx service, or “Run As”, account.
Allow user to choose – The publisher will determine the workflow authentication at the time of publishing.
Let’s dig deeper into what this means and why it matters.
What is workflow authentication?
Workflow authentication is different than how you authenticate with Alteryx Server itself. Your organization’s Alteryx Server might sign you in with your windows credentials, but you depending on how workflow authentication is set up, you may get an additional prompt for credentials when you actually go to run a workflow.
The key difference is that when you log in to Alteryx Server, you are authenticating to see the content that applies to you on Alteryx Server itself. IE, the collections that have been shared with you and which studio you are a part of. Workflow credentials control who the workflow itself is being run as. This could be with a service account or your own login details. The key differentiator is most common when accessing shared drives.
An example of why this matters
Let’s say I run the a workflow in Alteryx Designer that uses Excel Workbook 1 from the shared drive above, which I, Aidan Bramel, alone, have read/write access to. When I run this locally and Alteryx Designer, this works like a charm! However, the Alteryx Gallery that this workflow is to be published to has its authentication method set as “Run as a different user”. How would we expect this to work on Alteryx Server?
Running this workflow on an Alteryx Server with this configuration and only “Aidan Bramel” having access to the share will result in a ‘File not found’ error due to invalid permissions. This is because the workflow is no longer running as Aidan Bramel, like it was on my local desktop. It, instead, is running as an Alteryx Server service account behind the scenes. In this case and in this configuration of Alteryx Server, that service account would also need access to the share.
However, if this server was set to prompt a user, or to allow the user to choose the credentials, we could set the credentials to run as Aidan Bramel, and we would see it run properly. This illustrates why workflow credentials matter.
Changing workflow authentication options
Unlike most configuration changes for Alteryx Server, this setting exists in the Admin section of Alteryx Gallery. Therefore, Curator permissions is required to change this, but not necessarily access to the back-end of Alteryx Server.
The control for this is under the Configuration tab under “Workflow Settings”. Here you will find a Workflow Credentials Setting, where you can select one of the three possibilities we discussed above.
You will also see a warning. Changing workflow credentials may disable schedules or prevent users from running workflows. This is due to the aforementioned requirements for both access for the account being run as, and providing credentials for that account. Changing this may also result in the need to republish workflows in order to set the proper credential setting. For this reason, the recommendation is to choose a setting for this and leave it alone for the remainder of your use of Alteryx Server.
Pros and Cons of each setting
Because you should not change this setting, it is important to make sure you’ve got it right to start with. Here are some high level pros and cons of each option.
Use Default Credentials
Pros
- No need to store or enter credentials.
- No need to update stored credentials when passwords change.
- More simple experience for the end-user running the workflow.
Cons
- Training associated with giving access to the service account.
- Giving one service account access to file shares all over the company can result in risk if those credentials are given to the wrong people.
Require User Credentials
Pros
- Heightened security for access to shared drives, with only those given explicit access to the file being able to run.
- Shared Credentials available in the Admin section for sharing credentials without exposing passwords.
Cons
- Need to update stored credentials when passwords change.
- Need to give all Run As permissions to any user that would use credentials to run a workflow on Alteryx Server.
Allow Users to Select
Pros
- Increased flexibility to tailor workflow credentials to the needs of the individual workflow.
- All pros of each of the above.
Cons
- Additional need for training users to make their selections.
- All cons of the above.
Conclusion
You can enable Alteryx Server using whichever way of workflow credentials is best for your organization, but it is important to understand the implications before you make your deployment. I hope this gave you a good idea of how workflow credentials are used and what may be the most practical way for your organization!
Do you have more questions about Alteryx? Talk to our expert consultants today and have all your questions answered!
