Macro not saving as workflow dependancy

[CSmith16]

Hello,

We have been facing some issues recently where pushing something into prod breaks the workflow because of incorrectly saved workflow dependencies. These are new workflows built from scratch and when being built were all done locally and not saved to the gallery. Our macros should be saved to the workflow directory and are not and thus do not actually ush the work made into production. How do we change the pathways to be saved to the workflow directory?

This is an example of how it is working now (Incorrect)

Spoiler

 And this is it when it is saved correctly:

Spoiler

 

 

[Raj]

@CSmith16 While saving the workflow on server make sure
you click on workflow options > Manage workflow assets > the the box next to macro

this will help to save it.

[alexnajm]

@CSmith16 I think what @Raj is saying is to make sure the box is unchecked when uploading to Server so the original path is kept. That is if you are using network paths for example. If the box is checked, it will package up a local copy of the macro with the workflow

In this case (and as I understand the problem), I might look at using relative paths so that you are referencing the workflow directory like you mentioned. Here's a couple of articles that discuss it a bit: File Paths and Alteryx & How To: Use Relative Paths (alteryx.com)

Here's another one as well that might help: Sharing Macros in Alteryx Designer and Server. However, this might require a bit more information to properly diagnose, so I would contact your AE to see what help they could provide with their SE!

[CSmith16]

Thanks for the info @alexnajm, unfortunately the issue I'm running into is that the macro isn't an available option on the workflow dependencies. It is saved to the network drive and the workflow uses that as the reference, but it does not show it in the dependencies.  

[alexnajm]

@CSmith16 that seems odd - the workflow has got to reference that macro if it's in the workflow! I might consider deleting then replacing it to see if this behavior persists. Otherwise we may need to see this more clearly via screenshots - alternatively your AE Vince may be able to help on a call

[CSmith16]

Forgive me I am not to familiar with the language, "AE" and "SE". I assume that is like our Alteryx Rep? If so, I have not actually been in contact with a Vince. In the past I would reach out to our rep who goes by Matt. Where would I see this information? The support portal?

[alexnajm]

AE = Account Executive (aka rep), SE = Solutions Engineer

Alteryx moved around a lot of accounts this year between different reps, I think last year it was Chuck with Matt O as the SE. I know just because I'm from the partner that has remained consistent over the past couple of years working with y'all. I asked Vince to reach out to you direct

[CSmith16]

Thanks Alex I really appreciate all the support!

[Erin]

We've been experiencing the same issue where the macro doesn't show up under workflow dependencies at all. Then when publishing to server, it isn't on the list to check or uncheck as part of the package. An error appears after posting that says it cannot find the macro.

After trial and error, I found that the trick is about the way the macro is added to the workflow.

• If I have the macro open in another designer tab first, and I then insert it by R click canvas > Insert > Macro > Click Macro Name -then it will show up in workflow dependencies. 
• However, if the macro isn't already open in designer and I instead R click canvas > Insert > Macro > Navigate to the macro's saved location - then it won't show in workflow dependencies. 

@alexnajm - Do you know if the workflow dependency list is driven by how tools are added to the canvas? Or do you think the 'work around' I found might be just coincidence? 

[apathetichell]

the explanation is - macros saved in your macros root directory are assumed to be not workflow specific and not eligible to be a workflow dependency. If you need this as a workflow dependency save it in a project directory vs the macro directory. This is expected behavior. But it is annoying...