Starting with version 4.0, templates may be placed inside folders rather than at top level. When you do this, the template will only be visible in the configuration of jobs (or other templates) in the same folder or a (recursive) subfolder. For example, job templates will be offered from the New Job link only inside the folder defining the template. As another example, a template using a nested auxiliary model attribute will only be able to select an auxiliary model in the current folder (where the main template is defined) or above; and if the base auxiliary model type is abstract (i.e. you can pick subtypes), a job based on the main model will only be able to select concrete subtypes from among those defined in the folder of the job or above.

This feature allows each team to maintain its own set of private templates, while still reusing some global templates if desired. Assuming each team only has Job/Configure permission applied to its own folder (using role-based access control), that team will only be able to make changes to its own templates, not those of other teams (which it might not even be able to see).

No specific permission is required to use a template, beyond being able to see that it exists (in the current folder or above), i.e. Job/Read; nor is any specific permission required to create a template, other than being able to create any item in a folder, i.e. Job/Create. This is because templates, when expanded, are simply shortcuts to configuration that you could have produced yourself anyway, so they should not generally be privileged or secret. However you may certainly deny configuration access to a template to some users while still making it available for instantiation, for example by defining an RBAC group on the template which filters out some roles. Alternately, you could define the template in the root of Jenkins or in a high-level folder, and then only offer job configuration permissions to most users in certain subfolders.