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.
I have built a workflow that will be run once a day, but another user will be running this workflow.
My question is: is there a way to "lock" the tools in the workflow to prevent adding/removing tools or changes to tool configurations, but still allow a user to update input files and run the workflow? There needs to be visibility into the workflow as it runs (there are several test tools), so I don't think turning the workflow into a macro will work.
Alternatively, is there any way to see if any modifications have been made to the workflow between runs?
you can make it into an app with the input file being the input and have another question where they can define the output file. The test tools can output to messages which can be viewed at the end of the run through logs. or you can write to another file if there are any messages/statuses you need to confirm.
I have a 2 step app (i run the app 2 times) that checks for consistency first, then i flick a switch and it then runs the data in production and updates the underlying database. The first output is a color coded PDF for the input files which highlights any issues i have before moving on to the second step.
RE: modifications between runs - not really. There is a .bak file that is saved when you overwrite a workflow/app that you can quickly archive to keep history. Then you can compare the files separately, but that's kind of a pain depending on how it's all setup.
An "easy" option that might still take some work would be to place each configured "locked" tool inside of its own unique macro, and store these macros as locked files, or in a location where the end user can't modify them. You can still connect tests and other tools to these macros, but it would lock down this specific tool configuration.
This still doesn't necessarily "prove" that the user did not modify the code by using a different tool, but you could at least mitigate this via workflow events, which you could set up to email a log after execution. If the tool ID changes between executions, or if the logging metadata changes in any way, that would show that there was a change.