nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Nested Workflows

awizardly

Currently Instantiating a nested workflow from a parent workflow that does some setup.
Once the nested workflow is started, I want to divorce it from its parent workflow.

I know I can do this with an external task that activates a customized version of the workflow instantiator cgi, but I am trying to see if the standard wftask element will be sufficient for my needs. This is somewhat related to the excess number of jobs that linger in the workflow show all jobs list when using nested workflows.

And I am guessing from my current development, they still have not fixed the phantom nested jobs problem.
Has that been confirmed as a "feature"? I know its an old question, but I see some serious problems with using nested workflows as I would like them, because of all the clutter this could generate.

Find more posts tagged with

Comments

Adam Stoller

Once the nested workflow is started, I want to divorce it from its parent workflow.
The nested (child) workflow from a wftask was never, and never intended to be, divorced from the parent - so ...
I know I can do this with an external task that activates a customized version of the workflow instantiator cgi ... uses either iwjobc -i on a job description file, or iwwft_compile.ipl on a WFT -- would be the way to achieve what you want.

This is somewhat related to the excess number of jobs that linger in the workflow show all jobs list when using nested workflows
Actually, I believe that is in reference to the nested (child) workflows remaining visible in the To Do List after they've ended and returned control to their parent - not the other way around (which is what you are apparently looking for).

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

awizardly

I have used iwwft_compile.ipl in the past but have found that I had need to customize it for my uses, which I have done.
Trying to avoid this usage, but I may have to go there.
The nested workflow behavior in general has to do with any extra jobs that linger in the view all jobs window that are no longer needed regardless of parentage.

I will most likely have to instantiate the spawned workflow via external task, or live with the parent task lingering.

jbonifaci

Your best option, in my opinion, is to re-architect your workflows to not use nested workflows. There are very few reasons that justify using them. Just because you can, doesn't mean you should.

awizardly

Is there a really strong general consensus against nested workflows? In concept they seem very flexible and meet my needs in many ways. Especially when I want to spawn independent areas for work based on user input. I don't have to reset the area on alot of tasks after the fact in an external task. I just fork a nested workflow for something like annotated review and this allows me concurrent review with annotation. The only real disadvantages I see are cluttering of the job console and some more work needed to pass information back and forth if needed.

Lee
Organic Inc
http://www.organic.com