We’re facing a critical SOX compliance issue with our scheduled integration jobs in Workday R1 2023. Our audit logs are not capturing failed job executions when they fail due to API authentication errors. The Integration Monitoring shows the failures, but they’re not being written to the audit trail that our external auditors review.
I’ve verified the Audit Trail scope assignment for our integration system user, and it has View permissions for Integration Systems. The OAuth2 scope configuration includes workday_audit_trail read access. However, when a scheduled REST API job fails with a 401 authentication error, there’s no corresponding entry in the audit log export.
Successful runs are logged properly, but authentication failures seem to bypass the audit trail entirely. This creates a significant gap in our compliance documentation. Has anyone encountered similar issues with Integration Monitoring permissions not flowing through to audit logs?
Let me provide a comprehensive solution that addresses all three focus areas you mentioned:
Audit Trail Scope Assignment:
The standard audit trail scope only captures post-authentication events. For scheduled jobs, you need to assign the ‘Integration System Audit’ domain to your integration system user, not just the generic ‘View’ permission. Navigate to Security > Domain Security Policies > Integration System Audit and add your integration system user with full access.
Integration Monitoring Permissions:
Your integration system user needs three specific permissions:
View Integration Events (captures all attempts)
View Integration Systems (shows configuration)
View System Event Logs (captures OAuth layer failures)
These must be assigned through a custom security group, as the default Integration System Security Group doesn’t include System Event Log access.
OAuth2 Scope Configuration:
Add these scopes to your OAuth2 client registration:
workday_audit_trail (you have this)
workday_integration_events (missing - this is critical)
Create a validation report combining Audit Trail and Integration Event data to verify complete coverage
This configuration ensures that authentication failures are logged through the Integration Events mechanism while successful executions continue to appear in the standard audit trail. Both feed into your compliance reporting. The gap exists because authentication happens before the audit context is established - these additional scopes create a parallel logging path that captures pre-authentication failures.
For SOX compliance, document this dual-path approach in your controls narrative, explaining that authentication failures and successful executions are logged through different but complementary mechanisms that together provide complete audit coverage.
This draft is based on general Workday knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
I’ve seen this before. The issue is that authentication failures at the OAuth2 layer happen before the integration context is fully established, so they don’t trigger the standard audit trail mechanism. You need to enable API Request Logging in addition to the audit trail. Check your Integration System Security configuration - there’s a separate permission for API Request Logging that’s independent of the audit trail scope.
We had the exact same gap identified during our last SOX audit. The workaround we implemented was creating a custom report that pulls from the Integration Event log rather than relying solely on the audit trail. The Integration Event log captures all authentication failures with timestamps and error codes. We schedule this report daily and append it to our audit documentation package. Not ideal, but it satisfies the auditors’ requirement for complete failure tracking.
Thanks for the responses. I checked the API Request Logging permissions and they were already enabled. The Integration Event log approach sounds promising - can you share what filters you use in that custom report to specifically capture authentication failures? We run about 200 scheduled jobs daily, so I need to make sure we’re only pulling the relevant failure events.
The root cause is that pre-authentication failures occur outside the integration execution context. Your OAuth2 scope includes workday_audit_trail, but that scope only applies to authenticated requests. For comprehensive tracking, you need three layers: 1) Integration Event monitoring for all attempts including auth failures, 2) Audit Trail for successful authenticated runs, and 3) System Event log for OAuth token validation failures. Each captures different stages of the request lifecycle. The gap you’re seeing is architectural by design - authentication happens at the API gateway layer before audit trail scopes are evaluated.
For the custom report filters, we use: Event Type equals ‘Integration Error’, Event Category contains ‘Authentication’, and Scheduled Job equals ‘Yes’. We also added a calculated field that flags any event with HTTP status codes 401 or 403. The report runs at 6 AM daily and outputs to a secured shared folder. Our auditors accepted this as equivalent to audit trail documentation since it provides the same information - timestamp, user context, error details, and job identifier.
One additional consideration: verify that your Integration System Security Group has the ‘View Integration Errors’ permission in addition to audit trail access. This permission controls visibility into authentication-level failures. Also check if your OAuth2 client registration has the ‘Log Authentication Failures’ option enabled - it’s not on by default and must be explicitly configured during client setup or modification.
Confirmed this resolves the missing failed run logs — adding the Integration System Audit domain security policy to our ISU immediately populated historical gaps in the audit trail.