Issues with ingesting Salesforce logs into SecOps

This is a known "gotcha" in the Salesforce-to-SecOps pipeline. The error regarding the Interval column is almost always a diagnostic for missing licensing or incorrect API versioning, and the JWT failure is usually down to a specific policy setting in the Connected App.

Here are the answers to your specific questions based on current ingestion requirements:

1. Is Shield/Event Monitoring mandatory?

Strictly speaking, no—but practically, yes for the default Google SecOps feed.

Google SecOps uses the EventLogFile object to pull logs. While Salesforce Enterprise Edition includes basic event monitoring (primarily Login/Logout and API Total Usage), it often lacks the hourly log generation capability.

• The "Interval" Column: This field was introduced to distinguish between Hourly and Daily logs. In many Enterprise-only environments without the Event Monitoring add-on, Salesforce doesn't even expose this column to the API because it only supports the default daily rollup.

• The Conflict: The SecOps feed configuration is hardcoded to query this field to manage deduplication and high-frequency polling. Without Shield or the Event Monitoring add-on, the query fails because the column is literally missing from your org's schema.

2. Has anyone used JWT grant without Shield?

Yes, it is possible to get the authentication (the "handshake") to work without Shield, but the ingestion (the "data pull") will still fail with the Interval error mentioned above once the feed tries to run its first SOQL query.

If you are seeing an Authentication Failure specifically on the JWT grant before it even tries to pull data, the issue is likely a configuration mismatch in the Connected App.

3. Common causes for JWT Failure

If your credentials (Client ID, Username, Private Key) are correct, check these three specific Salesforce settings:

• Permitted Users Policy: This is the #1 cause.

  • Go to Manage Connected Apps > [Your App] > Edit Policies.

  • Ensure Permitted Users is set to "Admin approved users are pre-authorized".

  • If it is set to "All users may self-authorize," the JWT flow will fail because a background service cannot "self-authorize" via a UI.

• Profile/Permission Set Assignment:

  • Even if "Admin approved" is selected, you must manually scroll down to the Profiles or Permission Sets section of the Connected App and add the Profile/Permission Set belonging to your integration user.

• The "Audience" (aud) Claim:

  • Google SecOps sends the JWT with an audience of [https://login.salesforce.com](https://login.salesforce.com) (for Production) or [https://test.salesforce.com](https://test.salesforce.com) (for Sandbox). If your Salesforce org has "Enhanced Domains" or strict My Domain settings, it may reject the generic login URL. Ensure your "API Hostname" in the SecOps feed matches your My Domain URL exactly.

The Workaround: Instead of the native Google SecOps feed, use a custom script (Python/Cloud Function) to:

1. Query the SetupAuditTrail or LoginHistory objects (which don't require Shield).

2. Send them to Google SecOps via the Ingestion API or Google Cloud Storage (GCS).

3. Use the Salesforce Parser in SecOps to map the fields.

Hi ​@dnehoda 

Do you know is there a way to send Salesforce Logs to bindplane → then to secops?  I have the same question as ​@chaitravimore  and trying to see what will be the next course of action without getting Salesforce Shield.