User Management


Deadline has its own user system, which is primarily used to tie users to Jobs. By default, users cannot control or modify the settings of another User’s Jobs.

Each user can configure their own user settings from the Monitor by selecting Tools -> Options. See the Monitor and User Settings documentation for more information on the available user settings.

Managing Users

Administrators can manage the all users from the Monitor. This is done by selecting Tools -> Manage Users in Super User mode, or as a user with appropriate User Group privileges. From here, you can add or remove individual users, and edit their user settings. See the Monitor and User Settings documentation for more information on the available user settings.


User Security

User Security settings can be configured in the Repository Configuration.



User security is the customer’s responsibility. To enforce user security, Super User mode can be enabled to disable administrative features in the Deadline Monitor. Super User mode does not disable database access or remote connection server. Users can still call DeadlineCommand or APIs to use those administrative features.

By default, Deadline does not enforce Enhanced User Security. This means that a user can switch to a different User and edit someone else’s Jobs. For some pipelines, this “honor system” will work fine, but for those looking for tighter security, you should enable Enhanced User Security, so that it uses the system user as the Deadline User. When this option is enabled, users will not be able to switch to a another Deadline User unless they log off their system and log back in as someone else.

It is also recommended that you add a Super User password if you are looking for enhanced security, as a Super User without a password would allow Users to circumvent User Job-editing restriction, as well as circumventing any restrictions imposed on them by their User Groups (see below).

User Group

User Groups allow Administrators to restrict what functionality is available to certain users, as well as make certain features accessible to others without requiring the use of the Super User mode.

Deadline automatically creates an ‘Everyone’ User Group, which always contains all Users, and cannot be removed or disabled. This User Group is also populated with the default Permission Settings recommended for normal users.

Managing User Groups

The User Group Management section can be accessed as a Super User through the Tools -> Manage User Groups menu in the Monitor.


The left side of this dialog contains the list of User Groups that have already been created in the Repository. There are also controls allowing you to manipulate this list in many ways:

  • Add: Will create a new User Group using the default options and feature access levels (equivalent to the default ‘Everyone’ group before modification).

  • Remove: Will delete the selected User Group from the Repository. Note that the ‘Everyone’ group can never be Removed in order to guarantee that all Users will at least be part of this group.

  • Clone: Will create a new User Group using the Options and Feature Access Levels of the currently selected group as defaults.

This list is visible regardless of which tab is selected, allowing you to quickly change which Group you’re modifying, and ensuring you’re always aware of which one is currently selected.

General Options

This tab contains basic higher-level settings for User Groups. Note that most of the features on this tab, described below, will be disabled when modifying the ‘Everyone’ group, since it is a special Group that must always be active and enabled for all Users.

  • Group Options
    • Group Enabled: This indicates whether or not this User Group is currently active or not. Disabling a User Group instead of Removing it altogether can be useful if you just want to temporarily disable access for a group of users without having to re-create it later. This is always true for the ‘Everyone’ Group.

    • Group Expires: This setting will cause a Group to only be valid up to the specified Date and Time. This can be useful if you are hiring temporary staff and know in advance that you will need to revoke their access on a certain Date. This cannot be set for the ‘Everyone’ Group.

  • Job Access Level
    • Can View Other Users’ Jobs: This setting determines whether or not Users belonging to the Group can see other users’ jobs.

    • Can Modify Other Users’ Jobs: This setting indicates whether or not Users in this Group should be allowed to modify other users’ jobs (change properties, job state, etc).

    • Can Handle Protected Jobs: This setting determines whether or not Users belonging to the Group can archive or delete protected jobs that don’t belong to them.

    • Can Submit Jobs: This setting determines whether or not Users belonging to the Group can submit jobs.

  • Default Monitor Layout: Here you can select a Monitor layout that was added to the Repository Configuration. This layout will act as the default for users belonging to this user group. The Priority setting is used as a tie breaker if a user is part of more than one group with a default layout. When a user selects View -> Reset Layout, it will reset to their user group’s default layout instead of the normal default. Finally, if the Reset Layout On Startup setting is enabled, the Monitor will always start up with that layout when it is launched.

  • Time-Restricted Access: This section allows you to set windows of time during which this Group is considered Active. This is useful if you want to set up permissions to change based on the time of day, or if you just want to lock out certain Users after hours. This cannot be enabled for the ‘Everyone’ Group.

  • Group Members: This is where you control which Users are considered members of the currently selected Group. Users can be part of multiple Groups. All Users are always part of the ‘Everyone’ Group, and this cannot be changed.

Controlling Feature Access

The other tabs in the Group Management dialog are dedicated to enabling or restricting access to certain Features on a per-group basis.

Each tab groups displays a different type of Feature, that represent different aspects of the end-user experience:

  • Menu Items: This tab contains all the Menu Item features, including the main menu bar, right-click menus, and toolbar items.

  • Job Properties: This tab contains all of a Job’s modifiable properties, and determines which ones a User will be allowed to change. Note that this is only for Jobs a User is allowed to modify in the first place, if he is not allowed to modify other Users’ Jobs (see section above).

  • Scripts: This contains all the different type of Scripts a User could run from the Monitor. This section is a little different than the others, because the actual Features are dynamically generated based on which Scripts are currently in the Repository. Note that all scripts will default to a value of ‘Inherited’, so make sure to revisit this screen when adding new Scripts to your Repository.

  • UI Features: This tab contains all the different types of Panels that a User can spawn in the Monitor, and controls whether or not a particular User Group is allowed to spawn them.

These Features are also grouped further within each tab into logical categories, to try and make maintenance easier.


There are three possible Access Levels that you can specify for each Feature:

  • Enabled: The members of this Group will have access to this particular Feature.

  • Disabled: This Group is not granted access to this Feature. Note, however, that Users in this Group might be granted access to this Feature by a different Group.

  • Inherited: Whether or not this Feature is ‘Enabled’ or ‘Disabled’ is deferred to the Feature’s Parent Category. Its current inherited value is reflected in the coloured square next to the dropdown; Red indicates it is currently Disabled, while Green indicates it is currently Enabled. Top-level Parents in a category cannot be set to ‘Inherited’.

If Users are part of multiple Groups, they will always use the least-restrictive Group for a particular Feature. In other words, a given User will have access to a Feature as long as he is part of at least one currently active Group that has access to that Feature, regardless of whether or not his other Groups typically allow it.