Application paths

Teams allows you to create unique rules for parts of an application that share a root path. Imagine an example application is deployed at dashboard.com/eng that anyone on the engineering team should be able to access. However, a tool deployed at dashboard.com/eng/exec should only be accessed by the executive team.

When multiple rules are set for a common root path, its subdomains do not inherit rules. For example, when setting rules for dashboard.com/eng and dashboard.com/eng/exec separately, dashboard.com/eng/exec does not inherit the rule set for dashboard.com/eng. Instead, the more specific rule takes precedence.

In the Teams dashboard, when adding a self-hosted web application, you can choose to protect the entire website by entering its apex domain, or alternatively, you can specify any subdomains and paths in the dedicated fields.

​Using wildcards in subdomains and paths

When you create an application for a specific subdomain or path, you can use asterisks (*) as wildcards. Wildcards allow you to extend the application you're creating to all the subdomains or paths of a given apex domain.

This is how to use wildcards effectively:

​Protect all subdomains of an apex domain

Using a wildcard in the subdomain field does not cover the apex domain.

​Protect all paths of an apex domain

Using a wildcard in the path field does not cover the apex domain.

​Protect multi-level subdomains

Using a wildcard in the subdomain field to protect multi-level subdomains does not cover that subdomain's top subdomain nor the apex domain.

​Protect multi-level paths

Using a wildcard in the path field to protect multi-level paths does not cover that subpath's parent path nor the apex domain.