Hey folks, hoping to tap into the collective wisdom here. We've been running Zscaler Internet Access (ZIA) for about eight months now, and while it's been great for general web security, it's become a real pain point for our Salesforce-heavy teams. Our sales and support folks are, frankly, mutinying because of constant timeouts, sluggish page loads, and "spinning wheels" in Salesforce.
We migrated from a traditional proxy setup, expecting smoother sailing, but hit this performance wall specifically with Salesforce (both Classic and Lightning). Other cloud apps seem fine. It feels like we're missing a crucial tuning knob.
Here's what we've tried so far, with mixed results:
* **Enabled "Accelerate SaaS"** in the ZIA admin portal. This helped a bit initially, but the deeper issues remained.
* **Adjusted TCP settings** on our Z-App connector profile, bumping up idle timeouts and tuning buffer sizes based on a support ticket.
* **Created a specific "Salesforce" URL category** and applied a less restrictive traffic policy (bypassing some of the advanced threat scanning for this category). This made the biggest difference, but security isn't thrilled about it as a long-term fix.
Our current config snippet for the policy rule looks like this:
```yaml
Destinations: URL Category - "Salesforce_Custom"
Users & Groups: "Sales_Team", "Support_Team"
Protocols: HTTPS
Action: Allow
Security Inspection: Disable Malware, Disable Advanced Threat Protection
```
The core dilemma is this: we want the security, but the layered inspection seems to be the culprit. The transactions are just so chatty.
Has anyone else fought this battle and found a sweet spot? I'm particularly curious about:
* Any specific **SSL/TLS inspection** settings that worked better for Salesforce's API calls and long-polling?
* **TCP optimization** parameters on the service edge that made a tangible difference?
* Whether using **Zscaler's PAC file** to route only certain Salesforce domains (like `mydomain.my.salesforce.com`) through ZIA, while letting other static content from `salesforce.com` go direct, is a viable path?
* If moving these users to a **dedicated, geographically closer Zscaler data center** (we're on auto-select now) helped in your case.
I'm knee-deep in packet captures and ZIA admin logs, and any real-world experience would be a lifesaver. We love the security posture, but the performance hit is starting to impact business metrics.
Thanks in advance for any pointers or war stories you can share!
—B
Backup first.
Your experience with "Accelerate SaaS" providing only an initial bump is very typical. That feature primarily addresses TCP connection reuse, but it doesn't help with the root cause, which is often the inspection of individual HTTP/HTTPS transactions within those persistent tunnels.
The security team's concern about your URL category bypass is valid, but it points directly to the likely culprit: SSL inspection. Salesforce's architecture, particularly in Lightning, involves hundreds of small, sequential API calls to numerous subdomains (like `na...lightning.force.com`, `content...salesforce.com`). When ZIA fully decrypts and inspects each of these requests and responses, the latency adds up multiplicatively.
Instead of a blanket bypass, you need a more surgical approach. Have you reviewed the exact inspection modules enabled in the traffic policy for your Salesforce category? Disabling "Advanced Cloud Sandbox" or "File Type Controls" for that specific category can yield most of the performance gain with a far smaller security trade off. The real killer is usually the "Data Loss Prevention" deep content inspection on HTTPS traffic.
— Harper
The move to a specific Salesforce URL category is a smart first step, but you're right that it leaves security exposed. Instead of bypassing scanning entirely, try creating a dedicated policy that only excludes SSL decryption.
The performance hit often comes from inspecting all those tiny, sequential API calls. So you'd still apply malware and IPS scanning to the traffic, but you skip the decryption step. It's a much easier compromise for most security teams to swallow than a full bypass.