Ahh ... if they need to be used elsewhere then that is a different story.  

I forget off the top of my head exactly how this would work, but you could potentially subclass your Org class and just add the parent cardinality relationship.  I *think* that should force the extent of the subclass to be embedded in the parent class ( @Dan Pasco?), which should automate the cascading delete for you without impacting the Orgs stored independently.  

Thanks chad - scripting automatic review failure is more involved than just scripting the calling of the API at deployment time (and not relying on RELOAD=1) so we'd probably go that route.  

If RELOAD = null is hardcoded for immediate removal than probably relying on that would be the more risky approach to change control in this case.  So we'd likely rely on "Set status = %CSP.Mgr.GatewayMgr.ActivateCSPIni()" for automation.

Thanks @Bernd Mueller  ... this is very helpful!

Do you see an issue with having RELOAD = 1 always in source control, even if it is removed from the environment copy?

I really like the idea of it reloading, but am concerned about RELOAD = 1 being removed from the copy sitting on our DEV environment where all changes originate ... it would be too easy for someone to accidentally upload a new version of the file without RELOAD = 1 being in the file, meaning it would propagate through our CICD pipeline without that value present and not automatically be activated in higher level environments.

Do you know if there is a way to prevent RELOAD = 1 from being removed from the CSP.ini?

The issue is that you need the logic to run synchronously in process so that it can actually write out the JavaScript as part of the response to the web client. If you job off the logic it will run in a separate process and there is no way to return the JavaScript to the caller because this is done asynchronously and the response has already been sent by the time your job will finish in all likelihood. If you need something to run asynchronously then use the #call() command in your CSP page.

@Pietro Montorfano - VSCode use with CCR is definitely supported.  You just need to make sure that your workspace is properly defined with isfs, etc to get you access to the files on the server.  Since CCR uses server-side source control hooks, you can actually have people using Studio and VSCode concurrently against your BASE Environment.

We've tried to make it as easy as possible by allowing you to export the VSCode workspace definition directly from CCR (credit: @Timothy Leavitt ).  Go to your Environment Details page and use the "Export (VSCode)" button on the top of your Environment list:

Please try it and let us know if it works for you.  P.S. would you mind adding the #ccr tag to your question so others can easily find it?