By authorizing queues for a group, you allow users of that group the ablility to bind those queues to configurations they have permission to edit. This is useful, for example, if you want that only one build can be performed at the same time (in order to save CPU cycles) for some projects. In order to do achieve this, you can create a queue with only one working thread, and create a group with only this queue authorized. Then assign users from those projects to this group. This way, users of that group can only use that particular queue, which will streamline all triggered builds, instead of running them simultaneously.

By specifying configuration permissions for a group, you allow the users of that group the access to certain configurations in the system, and define operations they can perform on those configurations. This is done by choosing the desired configuration subtree, and set appropriate permissions on that tree. All configurations under the chosen subtree will get specified permissions. There are three types of permissions:

For a particular configuration, if it is affected by multiple permission definitions, the actual permissions will be the highest possible permission. In order to demonstrate this, let's assume that the configuration permissions are set as below:

Although second permission line states that all configurations under root.department1.project1 have View permission, but because the first line states that all configurations under root.department1 have Admin permission, configuration root.department1.project1 will take Admin permission which is the highest possible permission. This rule also applies when determining permissions for a configuration that is affected by multiple groups assigned to the same user.