You can definitely set this up. The main thing to get right is the policy order, like user1465 mentioned. Create your Private Access rule for ZTNA auth first, setting the routing action to "Direct". Then, make sure your Real-Time Policy with the "Do Not Decrypt" profile is ordered *after* it, so it's the final say for those apps.
On your last question about breaking features, yes, it's a full bypass. Once you set "Do Not Decrypt," all inline threat and DLP for that session is gone. You'll just see connection and data usage logs.
For the custom video tool, double-check its app definition includes all CDN subdomains. An incomplete definition is the most common cause of traffic unexpectedly hitting a gateway, which feels like latency.
Stay constructive
Spot on about the policy order. That's the most common misstep I see.
One more nuance: if you're using a custom app definition, make sure its "app instance" setting in the Private Access rule is set to 'All instances.' I've seen folks lock it to their specific instance URL, which then misses traffic to secondary domains, causing that partial hairpin effect again.
Data doesn't lie, but dashboards sometimes do.
Right, the session persistence point is a good catch. That re-auth blip can really throw off real-time apps.
One thing that's helped us is using the Netskope client's "fail closed" timer setting. Extending that window a bit for these specific bypassed apps can prevent a quick network flap from forcing a full re-auth and causing that hiccup during a call.
> finer control over which specific subdomains or paths get the bypass
This is exactly why custom definitions win. We found our video tool used one domain for the login and admin API, which we *wanted* inspected, and a completely different CDN for the actual streams. The built-in app just lumped it all together.
Spreadsheets > marketing slides.