community
cancel
Showing results for 
Search instead for 
Did you mean: 

Alteryx Designer Ideas

Share your Designer product ideas - we're listening!
Upgrade Alteryx Designer in 10 Steps

Debating whether or not to upgrade to the latest version of Alteryx Designer?

LEARN MORE
Alteryx Gallery is experiencing a problem in which system emails are not being sent out. As a result, if you are attempting to sign up for a new account, you may be unable to verify your email address. We are working to solve this as soon as possible and will remove this notice once resolved.

set a log location by workflow for local designer

There is a great question in the Designer space right now asking about saving logs to a database: https://community.alteryx.com/t5/Alteryx-Designer-Discussions/Save-workflow-messages-log-in-database...

 

This got me to think a little more about localized logging options in Alteryx.

 

At a high level, there are ways to accomplish this in Designer at a User or System level by enabling a Logging directory and then parsing those logs with a separate Alteryx job.  However, this would involve logging ALL Designer executions, which seems like it may be overkill for this need.  A user can also manually save a log after each execution, although this requires manual intervention.

 

I think adding an option in the Runtime settings for Workflow Configuration to Enable Logging and (optionally) specify a Logging directory would be a great feature add for Designer.  In my opinion this should not apply once a workflow runs on Server (Server logging should be handled in a fully standardized way), but should apply to designer "UI" execution.  Having the ability to add a logging naming convention (perhaps including a workflow name and run date in the log name) would be icing on the cake.

 

This would allow for a piecemeal logging solution to log specific flows or processes that might be high visiblity or high importance, while avoiding saving hundreds or thousands of logs daily of less important processes, and of dev test.  It would also reduce or eliminate a manual process to save these logs individually.

1 Comment
Aurora
Aurora

Fully agree with you @Claje - we would be supporters of a mechanism to drive central logging in a common way in a well managed database table - that way in a large enterprise you can start to track across your entire infrastructure for things like performance, who is accessing which lookups - and you can also create a "log this" tool which allows folks to explicitly log things like ETL lookup failures on an enrichment of a field.