Jaymer Scheduled a process which normally runs fine and it crapped out - even though I set the Session values specifically. One reason it crapped out was a process was checking LoggedInRegularUser - which, according to BobK's excellent answer here is NOT available on a Scheduled 'System' task.
kklosson If you mean it completely stopped running, I noted a while back that scheduled processes suddenly became sensitive to the format of the time, i.e., IF CURRENT_TIME='03:00', not IF CURRENT_TIME='3:00'.
aware_support For scheduled items there is no logged in user and there is no session, so the Session object will not work.
Jaymer aware_support wrote For scheduled items there is no logged in user and there is no session, so the Session object will not work. I hear what you're saying... but this works for scheduled processes, correct? Is this unexpected behavior and could go away in a future build? IF LoggedInRegularUser.AccessLevel='System' THEN ... From this post from BobK: How to check (in a Rule) if a Scheduler job is running? (comment)
aware_support Not sure I understand the question. It's by design, it's not a bug. Processes started from scheduling cannot use logged in user or session object.
Jaymer aware_support wrote Not sure I understand the question. It's by design, it's not a bug. Processes started from scheduling cannot use logged in user or session object. The Q is that BOTH BobK and I use this statement with success: IF LoggedInRegularUser.AccessLevel='System' THEN ... and thats the opposite of what you say is supported.
Jaymer @Vlad Also, please see this important issue; Can I have more that 1 Appointments type Group? v8.8
aware_support I stand corrected about the logged in user - you CAN check for SYSTEM. But session objects are only created when the user logs in.
