Folder Capture Node, no Input handle

I have a job where, upon completion of an ALL-IN-ONE operation, I want to do a folder capture. The job has two data files, two sets of resources. The second template uses a Dynamic Background script to ingest the PDFs output from the first file.

My initial thought was to add a “complete” node to fire when the “all in one” was finished, which would then perform my second “folder capture”.

However, the “folder capture” node doesn’t have an input handle, so cannot be fired upon “complete”.

Yes, I can attach the second “folder capture” to the output of the “all in one”, but that raises concerns about latency, as the “all in one” uses Separations and can have 100s of output files.

(EDIT: No, actually, I cannott attach a “folder capture” node to the “all in one”, “complete”, or any other node because there is no input handle.)

You could copy/store the resulitng PDF into a folder which would be watch by the folder capture node.

It isn’t the resulting PDF that I needed to capture. I ended up capturing both files with the initial folder capture, and then basically did what you said: upon “complete” of the All-in-one, process the second data file. That required me to first add a “change” node to delete the ManagedFileId, as the second data mapper was ignoring its own UI entries in favor of the “stale” ManagedFileId from the All-In-One.

Still, I think there are plenty of use cases for having a Folder Capture node that accepts an input, just as with the Folder Capture in Workflow currently.

Any specific reason the folder listing node couldn’t be used for this, combined indeed with a complete node to start that part of the flow? That node has an input.

We just now (yesterday) published an improved version 0.9.17 that makes it possible to get an array of objects out of folder listing, so you can get the same type of data out of it as from the folder capture node. As opposed to only an array of file paths up until yesterday.

Yes, that’s what I ended up using instead of folder capture.

Finding workarounds can either be fun, or stressful! I look forward to testing the new folder listing. Another job I migrated to Automate relies currently on a 3rd party “file stat” plugin to get the Date Modified value of each file in the array generated by Folder Listing. Removing that dependency (or any dependency outside of OL Nodes + Core nodes) is a Very Good Thing.