This document is current for 3.6 and 3.7 of the Pentaho BI Suite.
The Pentaho Admin Console -> Scheduling xaction section
Depicted below is the Pentaho Administrative Console interface typically used to configure the BI Server itself. The administrative console generally does not do anything extremely sophisticated. Usually altering settings on the various menus cause changes to be written to .xml files contained in the pentaho-solutions/system directory. For our case, changes will actually take place in the Quartz scheduler, which stores it's configuration in a database, typically MySQL.
Rules of engagement
It is important to know that when you create scheduled items on the screen above that without exception they execute as the user you have defined as the 'system user'. On a default install this is usually 'joe' with the samples, or 'admin' without samples. You will see we choose the user 'dtruty' as it is a valid username in our setup. Valid means that it is a real user account that has permissions on our network and will not disappear.
This brings us to some extremely important points about execution.
1. No startup xactions run before or after a scheduled xaction is run. If you want session variables, you'll need to add them as a sub-xaction of whatever you're scheduling. The reason is you can only schedule one single xaction to run per schedule, but you can create as many schedules as you like.
2. No roles normally associated with the user are assigned to them when things are run through the scheduler. This means you cannot use Mondrian, Analyzer or any other component that depends on roles, because these roles will not be passed on to Mondrian. You can have a completely open schema, but this means that you will have separate caching for each schema in Mondrian. One for your secured schema that depends on roles, and a separate cache for the unsecured schema.
In the picture below the Platform Administrator User Name is "dtruty". If you were to schedule a report that used env::principleName, the value returned would be dtruty. No roles or other session variables would be available to the report unless your xaction explicitly set them.
Examining the meaning of the word group.
Where you see the word "Group" in the picture is the name you are giving to the particular schedule. It has nothing to do with a role, access group or any security related concept. Groups simply allow you to schedule say two separate kinds of things to happen at different times under one name. You can make the schedules public and by doing so, other users who through the Pentaho User Console decide to schedule their reports will be able to have them run attached to the schedule you made public. This does not mean that other users gain access to whatever was scheduled by the individual in the Pentaho User Console.