Developing a team Alteryx library

[jackfyfe]

Hi community!

I'm at a new role as an accountant with an organization that's recently pushing Alteryx implementations. I love Alteryx so far, and I'm excited every time I solve a problem and can share that new knowledge with others who are still at beginner levels. I have this vision of creating a library of macros as we develop our own workflows and segment them into pieces with versatile utility. Are there any best practices you've seen for getting buy-in and documentation on team-developed macros?

We have a challenge coming up where each participant will present a workflow they've built in alteryx and be judged based on its effectiveness and usefulness. I had an idea: what if I could create book-end pieces that could extract a workflow segment and make a macro out of it, but when the bookends are applied and run, they launch a user interface requesting documentation-type fields (author, purpose, tags, etc) and then saved the macro to a shared folder, and saved the user-input documentation responses to a shared excel file adding a row to create a living library? Is this idea wildly out of scope for a beginner?

TIA

[DanM · Accepted solution]

@jackfyfe  Welcome to the Alteryx Community! Glad to see that you are already getting value out of the platform.

Your idea is definitely an interesting one, but it's quite complex in practice. To automate the creation of a macro from existing workflows, you'd first need to understand the specific parts of each workflow you'd want to extract and reuse. This requires a deep understanding of the workflows' logic and structure.

Since Alteryx workflows are stored as XML, you technically can parse the files to isolate specific elements. However, the challenge lies in not just extracting those parts, but also reconstructing them accurately as a functional macro. Macros require additional tools and configurations—like interface tools and control parameters—that must be added and set up correctly, which adds another layer of complexity.

Given the effort involved, it would likely be more efficient and sustainable for the original workflow creators to identify reusable components and manually convert those into macros. They can then save them to a shared library, as you suggested. This approach ensures quality and proper configuration, without the overhead of building a fragile automation layer.

[Mathias_Nielsen]

We use a network drive to store our macros, so that every user can access them. This is also basically a requirement if you use the Alteryx Server (Which we do). As it will also need to acces the macros.
We use the comments and containers to document functionality inside the macros. In the interface of the macro we use a text box with a default text to display documentation about functionality and What each input/output does.

[KGT]

I agree with @DanM, that the effort to productionise that would get tired real quick. I'm pretty handy with just about all aspects of the tool, but I wouldn't try to automate the macro production. You will inevitably have someone with one extra field or a letter where a number should be and your messaging will be default. I do think it's a great idea to set a standard for what people submit and then have a team look at them to create macros out of them, but who has the time with timesheets and billables... Also, not sure if you've found it yet, but select the relevant part of the workflow, right-click and "Create Macro". Most definitely quicker than automating it.

I've set up in our team (Accountancy firm), a similar approach to what I used to train teams with. I'm currently fighting against losing Network drives though as I don't think it'll work on Onedrive/Sharepoint.

Each member of the team sets up a macro repository (User Settings), pointing to the team folder on the network drive that we all have mapped to Z. I also get them to set up their own local one at the same time (Can be on Onedrive as it'll always be your path).

Then team macros appear for all in the team folder. I am really robust on what gets into that folder though, and I'm thinking about locking anything that does (Locked Macro can never be opened). Then I can keep the working copies on Azure DevOps or another Git, or just in a folder next to the main one. Haven't implemented that yet but we have't had anyone try and edit a production macro yet. Those macros will be used in hundreds of workflows, and so it's important that they don't get changed.

Those folders can be scripted on the install as well. They are just an ini file in the ProgramData folder.

Some cautions:

Try to avoid having a nested file structure that has a macro folder and the Production Macros in a folder within that. You will inevitably wind up with someone using the wrong one and another user not being able to connect to that macro as they don't have the higher folder mapped.

Also, try and avoid having CReW Macros etc in there unless you lock down anyone being able to install them elsewhere. People using macros from local and thinking they are global is the biggest risk.