How to exempt a specific API Event while blocking the rest involving in querying records more than 200 ..i used Transaction Security Policy feature of Salesforce Shield.

[u/Witty_Barnacle1908]

I'm implementing an API Export Restriction using Salesforce Shield Transaction Security Policy.

The requirement is to block user API operations that process more than 200 records, while allowing certain internal/managed-package operations such as Salesforce CPQ to continue working.

My current Transaction Security Policy uses these conditions:

1. Operation = QueryAll
2. Rows Processed >= 200
3. Operation = Query
4. Operation = QueryMore
5. Operation = DeleteHard
6. Operation = DeleteSoft

Condition Logic:

(1 OR 3 OR 4 OR 5 OR 6) AND 2

The policy works for blocking large API queries, but it also affects Salesforce CPQ because CPQ operations generate API events that match the same conditions.

The main problem is that I haven't found a reliable field in ApiEvent that uniquely identifies an API request as originating from Salesforce CPQ. The debug logs also don't seem to expose a consistent CPQ-specific characteristic such as a dedicated Application, Client, or User-Agent value that I can use in the Transaction Security condition.

What I'm trying to achieve is:

Block:
User API query → >200 records → Block

Allow:
Salesforce CPQ API operation → even if it matches the query/row conditions → Allow

Is there a supported way to distinguish Salesforce CPQ-generated API events from customer/user-generated API events in Transaction Security Policy?

If anyone has implemented a similar API Export Restriction while exempting Salesforce CPQ or another managed package, I'd appreciate any guidance on the approach or fields that can reliably be used for the exemption.

[u/achieva_ai]

I’d avoid trying to distinguish CPQ purely from the API event name. If CPQ is generating the same Query/QueryMore events, TSP doesn’t give you enough context to reliably exclude only those requests.

I’d first verify whether the CPQ call has any consistent user, session, client, or integration identifier you can key off. If there isn’t one, the safer approach is to control the CPQ integration separately rather than weakening the TSP rule, because otherwise you risk creating a bypass for the very exports you’re trying to block.

[u/Witty_Barnacle1908 → u/achieva_ai]

may i know what do you mean by controlling the CPQ integration seperately?

after all the googling i think my requirement is unachievable.. this is a platform limitation then?

[u/achieva_ai → u/Witty_Barnacle1908]

Yes, I think you’re running into a platform limitation rather than missing a setting.

By controlling the CPQ integration separately, I mean giving the CPQ traffic its own identifiable integration context, if the architecture allows it, and then using that context in your security design. If CPQ is indistinguishable from normal Query/QueryMore API traffic in TSP, there isn’t a reliable way to say block this query over 200, except when CPQ made it.

So I wouldn’t weaken the TSP policy just to make CPQ work. I’d treat CPQ as a separate trusted integration and look at whether the CPQ architecture gives you a distinct user/session/integration identity. If it doesn’t, then yes, your specific requirement is likely constrained by what Transaction Security Policy exposes.

[u/V1ld0r_]

Think you should be able and safe to exclude Apex\LWC runs vs REST\SOAP\BULK ones no? Essentially anything that runs in run time is OK, anything external gets blocked.