Job Group Properties
The Job Group Properties window is displayed when you create or edit a Job Group. To view or modify the properties for a group, right-click the group's name in the Console Tree or the Job List and select the Edit... or View... command.
Property Pages
Group
The Group page defines general settings for the group.
Name
Provide a descriptive name for the group (255 characters maximum). The name can be changed at any time. The name must be unique within the parent group.
Description
Enter any extended descriptive information or notes for this group. There is no limit on the length of the text.
Hold Status
The Hold Status determines whether and how jobs in this group (and its sub-groups) can be executed.
- Inherit from parent. When this option is checked, the group inherits the hold settings from all groups above it in the group hierarchy. Uncheck this option to configure the hold settings explicitly for this group.
- The parent groups may be configured to not allow their hold settings to be overridden. In this case, the protected options will remain disabled after you uncheck the Inherit option.
- You can always add additional hold types, even when inheriting hold settings. For example, suppose the parent group is configured to Hold triggers and also configured to not allow override of the setting. At this level, you cannot remove the Hold triggers setting, but you can additionally check any of the other hold options.
- To determine where the group is inheriting its hold settings from, turn on hold indicators in the Console.
- Hold triggers. All Triggers defined for the job are ignored. Note: This option holds all triggers for the job, not just Schedule Triggers.
- Prevent chained execution by other jobs. Any Job Control Actions and Job Execution Tasks that target the job will be prevented from executing it. adTempus will log an error message in the job log for the calling job, indicating that the target job cannot be run
- Prevent manual execution. Users will be prevented from executing the job on-demand using the Run command or the adtexec utility.
- Allow override. When this option is checked, groups and jobs below this group can ignore the hold settings from this level and set their own. When this option is not checked, groups and jobs below this group can add additional hold types, but they cannot remove the hold type(s) configured at this level.
Cycle ID
Check the Use this group as a cycle scope option if you want to be able to assign Cycle IDs for jobs run in this group. Once this option is checked, you must configure a job to update the Cycle ID to mark the beginning of each cycle. See the Cycle ID topic for more information.
The current Cycle ID for the group, if any, will be shown here.
Variables
The Variables page defines Job Variables that are inherited by all jobs and groups in this group. You may add, modify, or delete Job Variables, or override the values of Variables that the group has inherited.
A Group inherits Variables from its parent group. The top-level (root) group inherits the server-level variables.

The Job Variable list shows variables defined for the current object as well as variables inherited from a higher level. Icons next to each variable in the list convey information about their inheritance:
![]() |
The variable is inherited from a higher level |
![]() |
The variable is inherited from a higher level and is locked (cannot be overridden) |
![]() |
The variable is inherited from a higher level and has been modified at this level |
![]() |
The variable is new at this level |
![]() |
The variable is inherited from a higher level and must be overridden (a value provided) at this level |
![]() |
The variable has been overridden (redefined) at a lower level. This icon only appears if you have analyzed variable usage (see below). |
When you hove the mouse pointer over the icon for an inherited variable, adTempus will show where the variable was inherited from.
Filtering the variable list
The variable list can be filtered to:
- Hide inherited variables (so you only see variables defined at this level)
- Hide variables that cannot be modified (inherited variables that are locked to prevent modification)
- Show only variables that must be overridden
Analyzing and viewing variable usage
5.0
When you click Analyze variable usage, adTempus searches for all the places where the variables are used or overridden. After this analysis is complete, new columns are added to the list to show, for each variable:
- Whether it has been overridden (redefined) at a lower level
- A count of how many times it is referenced (used)
Clicking Show variable usage opens a new window showing all the references and overrides for the variables. This is the same window shown by the Find Variable and Function References tool.
Analyze variable usage only finds references and overrides that are "below" the current level. For example, if you are viewing the variables for a job, this will find all references and overrides within the job, or within jobs that may receive variables from this jobs (jobs run by Responses or Job Triggers). If you are viewing a group, this will find all references and overrides within groups and jobs below the selected group. That is, the tool only lists places that might be affected by changes to the variables in the list.
This tool does not show other places where the variables might be used. For example if you are viewing job A and some of the variables are also used in job B, those uses will not be listed unless there is a link between job A and job B.
To find all references to a variable:
- If the variable is defined at the server level, use the Analyze variable usage tool from the variables list at the server level. This will show all uses everywhere in adTempus.
- Use the Find Variable and Function References tool to find a specific variable or all variables.
Responses
The Responses page defines responses that will be executed for all Jobs in the group (and its sub-groups). Configuring Responses at the group level allows you to easily apply a standard configuration to all jobs. For example, if you want to always send a notification message to the same group of people if a job fails, you can configure a failure Response for the group, rather than configuring a Response for each individual job.
The events that you can configure Responses for at the group level are the same as those available for jobs.
Exclusion Periods
Version Compatibility: Server version 5.0 or later
Console version 5.0 or later.
The Exclusion Periods page defines the Exclusion Periods that apply to the jobs in this group (and its sub-groups). Exclusion Periods define time periods during which jobs will not be executed. On this page, select all the Exclusion Periods that should apply to the group.
Security
The Security page is used to view or modify the security settings for this object. See the Security Editor topic for more information on editing security settings.
Permissions set for the group are inherited by jobs within the group.
The following permissions apply to Job Groups:
Permission | Description |
Full Control | Permission to perform all actions on the group. |
List/Reference | Permission to list this group. |
View | Permission to view the properties of the group. |
Create jobs and groups in this group | Permission to create new jobs or groups in this group, or move existing jobs to this group. |
Modify | Permission to modify the properties of the group. |
Delete | Permission to delete the group. |
Administer security | Permission to change the security settings for the group. |
Change owner | Permission to take ownership of the group. |