@ShawnBerk  Thanks for your reply !

Are you saying that there is logic built in by the business where say, if you call (completely random example) customer_order_api.new__ (to create a customer order) within a PLSQL Codeblock, rather than a Projection CRUD Create Operation, and if that codeblock is originally called as part of a custom action set to a completely different projection and triggered through an event workflow, the actual insert might fail ?

I’d have thought that at the point you reach the PLSQL Codeblock, you’re “free” from the constraints of projections at that point, you just use the underlying PLSQL Package Methods and completely disregard any projection action (obviously this requires knowledge of the underlying schemas etc.)

Is that not possible?

Like I said, that is my recollection the last time I took a deep dive into the problem.  I would have to get the developer to dig back into this and confirm that is still true with a newer version (that maybe we’ve not installed).  What version are you testing with?

Recall I mentioned we are actually spinning our wheels on the entire project, not just this one bit of function.  There are major issues with the entire sales module that cannot be replicated in Cloud and functionality that is never planned, Service is miles away from where we’re coming from which is currently the Astea service product.  Engineering is an entirely new module for Cloud for us and doesn’t hold the same rigid Revision control that we’ve used in our existing PLM system.  It goes on and on, even if the BPA workflows have crept forward and you’ve found that it is possible to get further than before, the number of blockers is still prohibitive for us.

@ShawnBerk Currently testing within 23R2 I believe.

Completely agree with you that there are some other drawbacks present, as we discussed, such as Advanced SQL Searches being gone, or the other changes you mentioned :)

I’m just trying to make sure I have some sort of path forward with specifically event actions and that I know all the very real limitations that might exist so that I can report accurately to company leadership and offer recommendations for moving forward (or not)

Since i stumbled upon this i want to chip in from a consulting point of view. I used to work for IFS and now work for Novacura. We have our lown low-code tool that is native in the IFS world, so it's interesting to see IFS coming up with a workflow tool integrated in IFS.

IFS Workflow is certainly a nice addition to IFS overall, but in areas still a bit immature. It is not and will not be able to ever replace the full flexibility of PL/SQL events. I would still consider it a valid approach in terms of the Evergreen approach. If you are a heavy user of PL/SQL events it will be a challenge to keep a large amount of these up-to-date with frequent IFS updates/changes. I think there is a lot of potential for IFS Workflows still and it will be interesting to see how much IFS is willing to invest into it.
One thing to consider is, that even Workflow solutions will have the need to be kept up to date after upgrades. With every update IFS releases a list of "Breaking Changes" with IFS projections that have had a change that would "break" existing projection calls (e.g. a new mandatory input field). So while the upkeep is less than pl/sql code it certainly is not null. For our IFS connector (in our Low-code tool Flow) we plan to built in an automastic diff check which will mark all changed projections we are using. A feature like this would definetely be helpfull for workflows.
If you want to extensivly built upon/around the existing IFS functionality this will come with increased upkeep cost in the future as the number of system updates increases.

One of the biggest upsides of IFS Workflows is that we can finally configure dialogues and even full workflows. Why we can't select LOVs from IFS in Fields there is beyond me though. We have to write our own custom enummerations IN THE WORKFLOW and cannot even add translations there. If i am missing something here please let me know.
It's not possible to use variables in workflow responses which means you can only return custom static error messages e.g. "There has been an error". Fortunatly there is a workwaround for this one, although it needs a bit of setup.  
REST Calls have to be configured in the workflow. It's not possible to use e.g. routing rules unless you configure get functions in the workflow to fetch the address for one. No application message will be generated to keep track of messages/responses...

There are plenty of more things which lead to my "still a bit immature" comment up above. A lot of theses features should not be hard to implement.

My overall summary for IFS workflow would be:

- You CAN probably replace a significant number of existing events with it
- It works fine for simple automatisations
- Starting with workflows can be very frustrating. I would not describe the tool as intuitive.
- If you  are good in PL/SQL setting up a workflow will take significantly longer than a PL/SQL event in most scenarios.
- As soon as it gets a bit more complex you need a bunch of workarounds (e.g. custom Quick Report ->  Projection for more complex queries involving joins) to make it work. IF you can make it work at all.
- The Option to have input into custom buttons and built guided workflows in IFS is gold

For us it's mostly a good addition, BUT that's including our own tool Novacura Flow in the equation. We finally have the option to deeper integrate with IFS via Button/Event AND give direct user feedback/stop the process.
We usually go by:
- If it's simple try to solve it with workflow
- If it gets more complex do a Rest Call and let Flow handle the rest. We just have A LOT more options and flexibility in Flow, development is a lot faster AND our newest version of the IFS connector will also start to automatically check for differences in projections after an upgrade and point out these.

We are all still making our experiences with Workflows. There is a lot of potential and it remains to be seen what IFS makes out of it.