Control Containers not working for excel file with multiple tabs

[lblaakman]

I have a workflow that outputs 6 tabs on a new excel file daily. I updated the workflow to use the control containers because the workflow was sometimes failing when the tabs were trying to output at the same time. I have tried rearranging the workflow multiple times and have even put the entire workflow for each tab in separate control containers. (I have confirmed that the control container outputs prior to the ones failing have data) All of the workflows I have made run great in designer but when I publish them to the server they will sometimes work, and other times will not due to the multiple tabs being output. Has anyone else ever had this issue with control containers and has found a solution?

Thank you in advance!

[aasmith8116]

Are you chaining the containers to each other or just the tools between containers?

[lblaakman]

I am connecting the control containers to each other.

 

[karenewilkins]

In your screenshot, I  see multiple outputs in each control container. If you're having issues, you might want to put each output into its own control container and then chain them together.

[lblaakman]

I have also tried that and still got access errors.

 

[karenewilkins]

Hmmmm. The only other thing I can think of is to verify your workflow dependencies for all output paths. Before scheduling my workflows, I check to make sure all the workflow dependencies have the UNC path - not just a mapped filepath. This would explain why the workflow operates correctly in Designer, but not in the Gallery/Server.

[bertal34]

@lblaakman What is the error you are getting?  Where are you trying to save the Excel file (network location, sharepoint, etc)?  Can you provide a sample of your workflow so that I can troubleshoot?  With dummie data.

[lblaakman]

@karenewilkins I am using unc paths

@bertal34 This is the error I am getting: 'Unable to create backup of \\limafs01\Lima\Lima One Capital, LLC\Servicing Operations\2_Servicing Operations\102_SFTP\Doc to Data\Outgoing\Loans Boarded Daily_2024-12-30.xlsx to \\limafs01\Lima\Lima One Capital, LLC\Servicing Operations\2_Servicing Operations\102_SFTP\Doc to Data\Outgoing\Loans Boarded Daily_2024-12-30.xlsx.bak: Access is denied. (5) (ToolId: 66)'

I have attached an example of my workflow with dummy data. The outputs will need to be updated though.

[20steven09]

Usually, one user in your organization is the person that the workflows run under when running them on Server. If that person does not have access to the network drive you are trying to pull data from or save data to then the workflow will fail. Find out who the server user is and make sure they are added to your network drives and that should fix this issue. 

[NeoInfiniTech]

Hello @lblaakman,

Can you try the attached workflow?

The issue you're facing might be related to Control Containers that run too fast and the operation not being able to be complete for the next container as the previous one might still not be finalized.

This workflow now contains a Download tool which downloads the workflow itself (to be able to use the Throttle tool with AMP), which is then processed at a speed of 12 Records per Minute, which means that each Control Container will wait 5 seconds after the previous Control Container finishes running.

The path generated might not work correctly on Server environment as I do not have knowledge of what that file path structure will look like (does it start with C: or \\), so the related formula might have to be changed for it to work properly.

I enabled the tools that write output, you might want to disable them before running the workflow.

As a final note, it might be a good idea to follow @20steven09's recommendation as it is possible that the cause of error is related to network drive user definition. I cannot tell for sure as I am not very knowledgeable about a solution for this specific issue, although I came across this error before. The Control Container feature was not yet released by Alteryx back then, but hopefully this method shared in the attachment might be a solution to ensure that there will be no writing errors.