Looking for advice on a specific compliance blocker we hit during our latest GDPR scrub implementation. We have an Architect flow designed to anonymize PII in ServiceNow records immediately after a digital channel conversation ends. The flow uses a Data Action configured with OAuth2 Client Credentials to call the ServiceNow Table API (/api/now/table/incident).
While the authentication handshake completes successfully, the subsequent PUT request to update the call_dtl field returns a 403 Forbidden error. This is perplexing because the same service account has read, write, and delete permissions on the incident table, as verified by our ServiceNow admins. We have also confirmed that the IP ranges for our Genesys Cloud tenant are whitelisted in the ServiceNow firewall rules.
The payload sent is minimal, containing only the sys_id and the sanitized string. We have cross-referenced the Genesys Cloud Data Action logs, which show the request is formed correctly. Could there be a specific CORS or header requirement in the ServiceNow Table API that the Genesys Data Action is omitting, causing the platform to reject the request despite valid credentials? Any insights into this permission mismatch would be appreciated.