Hi ​@asubramaniam, What you’re running into is a real limitation of what most admins can self-serve from the Security & Compliance area: those “audit logs” are generally oriented around UI/admin actions, and they typically won’t give you a field-level trail for backend writes coming from an integration/API job.
For non-UI updates (like Candidate Sync from SAP SuccessFactors Recruiting → Eightfold TA), the most reliable “what changed / what wrote it” evidence is usually in the integration processing logs, not the Security & Compliance audit views.
Â
Where to look for backend / integration-triggered update logs
Â
1) Integration execution logs (SuccessFactors webhook/API processing) — backend logs
For SuccessFactors webhook-driven activity (and, in practice, many integration event flows), we can trace the incoming events and processing outcomes in backend logging. The SuccessFactors webhook implementation guide explicitly calls out tracing events via Redshift logs, including the webhooks_log table (and shows example queries that filter by group_id, system_id, and time window).Â
This log pattern is valuable because it can show:
- that Eightfold received an event payload,
- whether it was queued and processed successfully (or failed),
- and the payload content (e.g., in
data_json) which helps identify if the source system sent the “wrong” email value.
It also notes that if the notification is processed, it can be seen in Diagnostics as well.Â
Practical implication: if email addresses were overwritten “in bulk,” you typically want to correlate:
- the time window of the overwrite, with
- the integration system id, and
- the webhook/sync processing entries around that time.
2) Diagnostics (platform-side visibility into processing)
That same guide indicates processed webhook notifications can be verified in Diagnostics (i.e., platform diagnostics rather than Security & Compliance audit).Â
Practical implication: Diagnostics is usually the closest “self-serve” place to confirm that something ran and whether it errored, but it may not always provide a full field-by-field before/after diff.
Â
3) Data Warehouse / SIEM publishing for “actions & audit logs”
Eightfold’s internal security/audit architecture explicitly references using the Eightfold Data Warehouse for “Actors and Actions (audit logs)” and publishing those logs onward to a SIEM for security/compliance monitoring and investigation workflows.Â
Practical implication: if your goal is an ongoing operational capability—“show me what actions happen on Eightfold data from processes that aren’t UI-based”—the scalable approach is typically:
- publish audit/action logs to your SIEM, and/or
- query those “actions/audit” datasets in the Data Warehouse layer (depending on what your Eightfold deployment has enabled).
