Official: Shield and Security Center

Hi Ajay, 

Client and ConnectedAppId being blank here is expected, documented behavior for this call pattern — not something you're missing or misconfiguring. 

- Client: "The service that executed the API event. If you're using an unrecognized client, this field returns 'Unknown' or a blank value." 

- ConnectedAppId: populates only when the call goes through an OAuth 2.0 authentication process. A SOAP login()-based session (which is what your middleware is using with the Partner WSDL) doesn't go through OAuth, so this field is genuinely null for that auth pattern — there's no hidden client name to retrieve, because Salesforce never captured one for this login method. 

So "Approved API Client" custom metadata, if it's keyed on ApiEvent.Client, structurally can't match this traffic — there's nothing populated to match against for a SOAP login-based integration user. 

Practical fix: base the exclusion on the integration User instead of the API Client. Since your middleware authenticates as a dedicated integration user for this backup job, update your exclusion logic (or the Apex behind the TSP Accelerator's policy condition, if it's exposed for editing) to check ApiEvent.UserId/Username against an approved list, rather than Client/ConnectedAppId. This is the standard workaround for legacy SOAP login integrations specifically because Client/ConnectedAppId are documented as unreliable for that auth path. 

Worth knowing for the medium term: Salesforce is moving away from SOAP login()-based API access generally — the "Allow any API Client" permission (used to let SOAP login calls bypass API Access Control) is being deprecated. If this integration can be migrated to an OAuth-based flow (Named Credential/External Client App using JWT Bearer or OAuth Client Credentials instead of SOAP login), ConnectedAppId would actually populate, and you'd get proper client-based governance going forward instead of working around a field that will never populate for this auth method. 

Given this touches the TSP Accelerator's underlying policy logic, this is also worth raising directly with your Salesforce account team/Shield specialist — they can confirm the exact supported way to add a User-based exclusion within that specific Accelerator's metadata model, since the accelerator's custom metadata schema may need a field added rather than just a different value plugged into the existing one.

Got a Workaround: To bypass the AppExchange login flow, log into the target org first in the same browser, then paste the URL into the address bar. Because you authenticate directly to your own org here, this path skips the AppExchange/Trailblazer OAuth handshake entirely, which is what was throwing the invalid_social_token error.

Production:

https://login.salesforce.com/packaging/installPackage.apexp?p0=04tal00000738jNAAQ

Sandbox:

https://test.salesforce.com/packaging/installPackage.apexp?p0=04tal00000738jNAAQ

As the error message suggests, this is a permissions issue with the user authorized in the TSP_Accelerator Named Credential. I'd recommend reviewing that user's profile and permission sets to ensure they have the permissions needed to create Transaction Security Policies. As mentioned here https://help.salesforce.com/s/articleView?id=005321565&type=1, there is a new permission "Modify Transaction Security Policy" that is required to create, update, delete, enable, or disable TSPs. This new permission is now included in the TSP Accelerator Permission Set that is included with the package.

Salesforce did create a couple help pages as follow ups to these questions.  The first link below summarizes all the June changes.  The second link is specific to the Phishing resistant MFA stuff.  These were posted May 5 and May 6 respectively.   

June overview  

Phishing resistant MFA 

Following up on this thread from a long time ago- Data Detect has since evolved and it's now part of the Shield app since Sept last year. It requires no installation and just needs assignment of a user permission. It currently supports scanning upto 100 objects (all fields) in a single scan which is set to increase dramatically in upcoming releases. There is no performance impact of this scan and provides you with ALL the results of the scan vs only 50 results per field in the Data Detect managed package. Scheduled scans are coming soon too! 

Storage Impact: 

Event Monitoring storage is "free"/included.  However, several of the TSPs function by using a custom object where a record is created for every event that comes in.  While events did not have an impact on platform storage previously, now they do.  Some of the events being monitored are high-volume in some orgs, and the impact to storage could be meaningful. 

The potential storage impact isn't highlighted in the User Guide at all, and the only mention I see is when activating certain TSPs an optional last step that is given (which is manual): 

"Optional: Activate the TSP - Delete Record Access Records Flow to delete unnecessary Record Access records" 

Thank you for delivering a record cleanup process, but the importance of this flow and the potential storage impact seems like something documentation should stress more.