In case anyone needs a workaround for this.. I did some more tests using Schedular & Menu initiated Processes, and used my AdminLogBO to record the results.
Results: (Solution/Workaround Below)
From BOTH Scheduled (No User Logged in) processes and Processes run from a Menu (User Logged in):
IN_CONTEXT('SessionObject') = 'Yes' ............ FALSE
IN_CONTEXT('LoggedInSystemUser') = 'Yes'' .... FALSE
Which renders IN_CONTEXT Useless for either of those.
From a Scheduled Process:
if LoggedInSystemUser.ID IS DEFINED then
(some code)
else if LoggedInSystemUser.ID IS UNDEFINED then
(some code)
else
(some code)
None of this executes from a scheduled process, including the last else
Which means we can't use LoggedInSystemUser.ID, because the Rule would crash (or get ignored?) when run from a Schedule.
Solution:
Schedular Calls ProcessA1
Menu or Query Operation Calls ProcessA2
ProcessA1 Creates a Session Variable ProcessSource with an attribute to say it's Schedular Initiated.
ProcessA2 Creates a Session Variable ProcessSource with an attribute to say it's User Initiated.
ProcessA3 has ProcessSource as Input (as well as any other inputs)
ProcessA3 checks ProcessSource to determine if it's a Scheduled Task or a User Initiated task.
ProcessA1 & ProcessA2 Call ProcessA3 using ProcessSource (as well as any other inputs)
The only downfall, of course, is any sub-processes that need to know Who/What initiated the process, will need to have ProcessSource as input, and it will have to be passed down the line.
It would be much easier if IN_CONTEXT worked for LoggedIn and Session Objects, that way we could just if/then/else when we needed to know who the boss is.
