Best practices
Learn best practices for building scalable Access applications and policies.
If you have many policies that contain duplicate rules, we recommend building a rule group and referencing it across multiple policies. For example, you could define a rule group for "corporate users", which has both device posture check requirements and specific emails, or just “developers”, which references a group in your identity provider.
Access applications have an inherently flexible and powerful domain structure capability. Your domain structure should achieve your application security goals without being overly permissive or overly restrictive. Before designing applications for production, review the Application paths documentation to understand how path definitions work and how to use wildcards.
Many customers who have workflows designed around internal web applications, especially those that were built internally, often see challenges related to interdependencies on multiple internal services. Separately, there can be challenges related to SPAs (Single-Page Applications) that make onboarding to a Zero Trust Web Access service difficult. For example, an application may have iFrames or other embedded systems that rely on different internal and/or external addresses.
If your internal service operates in this way, we recommend specifying multiple top-level domains in a single Access application. Otherwise, if the goal of using multiple domains is to streamline or simplify policy creation, we recommend making one primary domain per application, and automating the rest of your deployment using Terraform or another Infrastructure as Code (IaC) service.