Best Practices for Sharing Macros

[JordanB]

As more and more users become familiarwith macros it is useful to know the potential ways of scalingand sharing these insights within your business.

Here are just a few ways to achievethis aim!

Push latest macros to users/automatically ensure that users are using the latest version

Alteryx Designer Desktop

Working with colleagues and sharing macros?

Within the Alteryx designer you can create your own macro ‘Parent Category’. When specifying a file path, you can choose either a local or a network/mapped drive. If you are building macros within a team and looking to share or update macros dynamically, having a mapped location will allow you to reflect any changes on everyone’s machines.

As a best practice when overwriting a macro it would be best to update the Meta-data tab (Within workflow properties tab) within the macro to add initials or details of what has changed. This can help you track who edited each version. Unfortunately, if you choose to use an overwrite function, you will be unable to control the version of the macro overtime.

Therefore, you may choose to add “V1” etc. to the macro when saving it to the network location. This macro parent category could then be used as a development location and then you could have another macro parent category where you publish production ready macros.

Alteryx Server

The Alteryx Server can adopt a similar outline to that of the Alteryx Designer however, it has a greater flexibility in terms of version control. When building a macro you can publish it with a description.

Then when a change is made to the macro you can press the save icon and add another description.

Within the gallery this is then reflected when you click on the macro and click on the version number. You then have the capability of running & publishing up and down versions.

Include macro pack as part of installation procedure for new users

You could zip all the macros together and get a user to extract them to their own macro folder (mentioned above).

Or to the Admin (C:\Program Files\Alteryx\bin\RuntimeData\Macros) or Non-admin (C:\Users\%USER%\AppData\Local\Alteryx\bin\RuntimeData\Macros) folders.

If you use the metadata tag when building the macro workflow it can land in that parent category as well.

Best,

Jordan Barker

Solutions Consultant

[dataMunger]

This is helpful and thanks for writing this.  Another method we for version control we have been working with is utilizing GIT to control changes to the shared network folder of Alteryx macros/tools.  This allows version control of the files without changing the tool name.  Thanks again for bringing up this discussion as this is a challenge we have encountered when scaling the use of alteryx.

[MichaelSu]

Hi @JordanB ,

Thank you for the write-up. This is super helpful.  So to be clear, if a user has a shared drive and wants to share macros on the Gallery...

The creator would publish his/her macro to Gallery. The individual at the desktop level looking to leverage that macro would then download the macro, save it to the shared network location, and ensure that the macros path in User Settings is pointed to that shared drive?

Thanks in advance! Always appreciate your write-ups on Community.

Mike

[JordanB]

Hi @MichaelSu 

If the use case is having the latest and greatest macro automatically updated within a workflow, then you want to just use network location and point to this within the Alteryx Designer for your own macro category.. 

The Gallery would be for useful macro's that are not referenced or need to be updated in many workflows at one time. A good example of this is our public gallery where you download useful predictive tools on a adhoc basis when you need them. 

Best,

Jordan

[ChrisOwens]

Hi Jordan,

Interesting read, sound like something we could use. Do you have any tips for his situation:

We have only one server, which doubles as production and development. As such we have a mix of Dev and Prod workflows on the gallery that we largely segregate by Collection.

In addition to this, we have a growing collection of macros used in these workflows, and each of these has a Dev and Prod version. These are stored on a network drive and separated by being stored in separate folders – I am starting to colour code the macro icons to distinguish them when used in workflows (green = prod, red = dev).  

We’ve had a recent problem where one of our team updated a critical macro that impacted many production workflows including a highly visible critical ETL.

What I want to do is restrict the changes of Prod macros until they have been certified. The current structure does not allow this, but these macros are used by 3 developers only with same access.

Thanks,

Chris