Destroy parent token from within a subflow

[elizabeth_lopez]

I want to be able to destroy a parent token from a sub flow. I know that as long as a child token exists you can't, but what if I destroy the child token along with the parent token? Can that work? How?

[matt_long · Accepted solution]

The only way to destroy tokens is to send them to a Sink or Finish activity. But you are correct in stating that a token that has children still alive will not be destroy until all its children are destroyed. If the parent is sitting in a Sink or Finish activity when its last child is destroyed, the parent will automatically be destroyed.

If you're in a Run Sub Flow activity, the parent will remain in that activity until all of its children have hit a Finish activity. You could then send the parent to a Sink.

If you're using a Create Tokens, then you could have the parent already sitting in a Sink. Hopefully this helps.

[elizabeth_lopez]

I was afraid of that. I have many places in a general process flow where this logic will be needed and I was hoping to not have to copy and paste everywhere, that's why I was looking for a sub flow solution.

[matt_long]

If you can share your model and explain what you're trying to accomplish we may be able to come up with a better solution.

[matt_long]

For example, do you have to have the parent-child relationship? The Create Tokens activity allows you to create tokens that are not children, allowing the original token to be destroyed without regards to the tokens it created.

[elizabeth_lopez]

It's a yield loss implementation. The attached sample is the way I think I'll have to implement it. In my real model, I have many tokens being created from distinct sources and they go through a set of sub flows in different order/combinations. So for example, after executing Sub Flow 1, I check the label and decide whether the parent needs to be destroyed. I do the same thing after Sub Flow 2. If I use this solution, I'll have to add a Decide activity after each sub flow run, that's what I was trying to avoid by only having this type of logic in the sub flows (which there's less of than sources).flexsimyieldexample.fsm

[matt_long]

I couldn't think of any really slick way of doing this, but you could at least simplify things down by changing your decide from sending it out connectors to sending it directly to the Scrap activities. I've attached an updated model. 6515-flexsimyieldexample.fsm