@kumaa33 Has anyone confirmed this as being completely true?  I ask because we have some jobs set up that spin up a queued process with the access group left as blank, and are seeing that the access group at runtime is actually running with an AccessGroup.pyAccessGroup value of "PRPC:Agents" (confirmed by giving the triggered activity a logging step).  All initial processing seems fine, as it knows about our ruleset stack, however ultimately, the job routes the assignment into an assignment shape that has an SLA defined on it.  When that SLA later fires, it fails because processing is unable to find the SLA instance, the reason being because PRPC:Agents does not contain our implementation code.

My issue may be stemming from what initially calls the queue-for-process method....the beginning of everything is a schedule.  Schedules also run under runtime process, but when they run, since they are system driven, what access group would the schedule run under?  My guess right now is that schedules actually run under the access group that is defined on the batch requestor (PRPC:Agents), so ultimately when our queue process is spun off, it is associated with the same access group.  Rule resolution is fine for initial processing, however if an SLA is later routed to, it is going to associate to the system access group, and will later not know about its necessary ruleset stack.