All SLA's run as user "SYSTEM" instead of running as the actual operator, and hence the choice of access group is a bit more complicated.

However, an access group is in fact chosen for each SLA agent job that is run, and that chosen access group determines what security roles and ruleset list prevails for the agent job.

Depending on exactly what Pega version you are on, take a look at activity EstablishContext at the java step to see how the access group is chosen.  /Eric

Hello Naveen,

Looking at the Pega help for PRPC 5.4sp2, I see that it contains the following note.

One of the Pega-ProCom agents enforces service level rules, performing escalation when the deadlines and goals in service rules are not met. If your application uses service level rules, ensure that the access group referenced in the Pega-ProCom agent schedules includes your application RuleSets and versions. You can update the PegaRULES:Agents access group, or maintain another access group that includes the RuleSet versions that cover all applications in your system that use service level rules. 

That version is one of the last before the SLA became processed by the queue manager. I suspect what you have found is a place where the help file wasn't updated to reflect changes in the way the system functions. With a modern version of the Pega platform, you don't need to supply an access group for the agent to process SLA items.

Thanks,

Mike