Script task

Really, only that the user can't directly interact with it.  Nothing with a saveInto will work.  Nothing only configured to work from within a saveInto will work.  

Am not getting you

Objects with a saveInto parameter won't work, for instance a!textField, or any form of link.  a!startProcess() (if I remember how to spell it) and a few other functions can only work from within a component's saveInto parameter.  Those will not work from a script task.

Anything that does not require user input is theoretically possible with a script task.

 thank you!

Something that isn't impossible but is pretty frustrating when you run into it -- the fact that you can't take one complex expression and save various elements of it each into their own PV.  This often means that you're either adding multiple outputs to the same script task (regardless of how redundant they are in functionality) to populate each PV, and/or chaining together mutliple script tasks to do consecutive-style processing.

Note that I don't exactly have a proposed solution in mind to this, but the fact that we still need to use such silly workarounds sometimes just underscores how dated and inflexible the functionality is.  That goes for the "output variable" system in general across most process model nodes, not just script tasks of course.

I'm also not a fan that you can't have a quick glimpse of the Target of all outputs in one view.  Say you have 30 Data Outputs, trying to find which one is being saved into a certain variable requires up to 30 clicks.  Additionally, for longer CDT names, the windows doesn't expand - cutting off part of the variable name.  More of an annoyance than a limitation however. 

But there is a limitation of 1000 calls when running as MNI.

Would also be nice to be able to set these as a "Run as Administrator" account, vs having to rely on the designer or process initiator.

Regarding your final point - the "designer" account should always be a system admin (at least in Prod).  And since they introduced service accounts, it's finally pretty easy to pull off without bending over backwards.

Yea, and that has been much better as of late with the Deployment capability.  I'm racking my brain, but we have had issues with developer accounts being deactivated which are tied to the PMs - been a while though..

I remember being thrilled when a plugin was released that let you publish PMs as the admin account using a smart service - still required a second step during deployments however.  Before that, you had to login to your browser with the admin account to deploy or re-publish (unless you wanted your name on production documents etc)..  Anyway, loving that deployment feature!  Only bonus there would be if we could deploy to multiple environments at once, since we're on the topic of limitations :) 

Mike Schmitt I assume you're aware that you can now use the Map type both as an output from a complex expression AND as a type natively within a Process. This means your Expression can be called once, return what is in effect an array of strongly typed elements, and get access to those elements directly in the process model. Or have I missed your point somehow?

Stewart Burchell - yes, in fact i mentioned this during an external conversation I had a bit later yesterday, referring to this thread (though it sorta slipped my mind when writing my above comment).  My mind is, however, still in the mode where I'd sometimes like to evaluate one expression and save different parts of the output into different PVs, without having to evaluate that expression multiple times or take multiple steps.  In such cases (admittedly pretty rare, when dealing with more complex process functionality) using a!map would work but would still be a workaround.