When creating workflow launchers I recently thought it a good idea to organize them within the /etc/workflow/launcher/config node by creating sub-node's to contain the customized launcher's organized by company name.

Given the fact that the models support this, I figured this would be similar.  The only need, I thought, similar to the model sub-nodes is that the subnode of config would have to be of the same type as the config node itself.  With the workflow model's, it works this way.

SIDE NOTE:  If I were a betting man (which I am every third year or so) I would bet that in an upcoming release they would add the ability to organize your models from the workflow console.  Right now, this is not possible.  You MUST use CRXDE Lite to accomplish this, or build it into the maven project containing your customizations.  

First, I would highly recommend that custom workflow models become assets that are part of your build. This is in order to ensure consistency of the application across ALL CQ instances where the app will be deployed: DEV, QA, PROD, etc.


Second, I would also recommend creating a folder structure to maintain your Models.  There are a couple examples OOTB.  The geometrixx related workflows are organized like this.  This will allow easier packaging.  It will also ease ACL configuration for the customizations.  This will give the ability to easily allow MODIFY rights to the custom models while denying MODIFY rights of the OOTB Models.

But that is just my opinion.

Back the original story...

SO, this part was so deceptive, it was the impetus of writing this post.  I dumped a good amount of time into trying to "solve" my problem based on the incorrect assumption that the methodology mentioned above works. 

The node type of the config folder is "sling:Folder".  I created my sub-node of config (for discussions sake called "mike") and then moved my custom launcher into this node.  After doing this I could still see all the OOTB launcher configurations in the workflow console including mine which were contained within the sub-node "mike".  I think everything is OK.

Time goes by, and my CQ instance is stopped and started many times.  Now, when I look at the launcher configuration in the workflow console all of the launch configurations are missing.  More than just that, there are no errors in the error.log neither are there any UI errors.  So I think I have hosed up my CQ instance, which happens at least once during a significant project.  I rebuild my CQ instance.

I won't belabor the troubleshooting I did.  In the end CQ does not like ANY sub-nodes of the config node.  I even moved my "mike" node elsewhere, stopped and started the workflow related bundles, then the OOTB workflow launch configurations now display.  I move my "mike" node back in, and now I see both my configurations in node "mike" and the OOTB ones.  I stop and start the workflow related bundles, and then they all disappear.

 

Conclusion:

Don't attempt to organize your workflow launch configurations beneath /etc/workflow/launcher/config by using sub-nodes of config.

 

One more thing: 

Even after 5+ years of working with CQ I still forget this.  Remember to click "Save" when you are creating and modifying a workflow Model.  If you don't, the workflow wont get kicked off.  Maybe sometime soon model modifications will be auto-saved and save us all wasted time troubleshooting our workflows, trying to figure out why they are not getting executed.

 

I hope this saves you some time.

 

Enjoy.