This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
Background: 6 months new to Alteryx. Learning that I have 15 workflows, flowing to multiple dashboards in Tableau. Long story short, starting to find it's not as intuitive on name conventions, organization, etc.
Is their a general best-practice for naming Alteryx Workflow files? Generally, should there be one output per workflow? (Not including that the output could do to multiple file types) Any Alteryx resources for enterprise file name organization/best practice?
I manage an Alteryx Server and a Tableau Server. The tableau server has 350 users and a large number of dashboards. All the source files, Alteryx flows, Tableau Files, and non database data sources are stored in a network drive. We tried a verity of options for organization a couple of years ago and I decided the best bet was to store the info in the network drive using the same folder structure we use in Tableau server. This makes everything easy to to find. (Department --> Project --> Dashboard)
Inside the network drive folder for each dashboard are a few sub folders (Flat Files = Any Excel / CSV Files used by Alteryx or Tableau, Documentation, Data Visualization = Tableau files, Data Prep = Alteryx flow, and Archive). I try to have everyone do one Alteryx flow per dashboard regardless of the number of outputs.The name of each output should be the name of the project plus the output number. For example "009 - On Time Payment - Output 1".
I also have a "Master" Excel sheet that lists every dashboard / flow along with every data source / flat file used and who owns it. This is done so that when people leave the organization, I can quickly see what they owned and reassign someone to update the data if there is anything manual (in most cases this is not needed as we have Alteryx server auto refresh everything ). What has really come in handy is when there is a database issue or an issue with another data input, I can quickly see which flows will be affected and have someone from my team notify the necessary parties.
Hopefully that helps answer your question. There is not one 'right' way to do this, but the above has greatly helped my team.