Some PDIs are currently unavailable, and PDI actions are paused. View the latest updates here. Read More

RAAS Report Servicenow WORKDAY

Ashutosh4
Tera Expert

Hello Team,

I have a WD Connection setup in the system and it works as expected like pulling data and all.
Now the customers have added a RAAS report in their Workday.

I tried to Raas report access detail.
sn_workday_hr_spke_raas_report_access_details This is the table and gave the name report name and user name, but it gives me an authentication issue. 
I am not sure how is it giving me authentication issue when we use the same creds to pull other WD Data.

The Report name and Report owner name i am extracting from the API endpoint and also, the USER ID I kept the same Report owner name and also tried with Client iD too.


Exact Error: Unable to Authenticate access token. Please check credential details in Connection and Credential Aliases of Workday HR Spoke.

Do the Raas report need to have some different ID PAssword or something ?

Also for the RAAS report they shared me and API endpoint, do we need to add it somewhere?
I have just used the report name and owner name in the Report details.


Ashutosh4_0-1785831268644.png

 




4 REPLIES 4

KPNow
Tera Expert

Hi @Ashutosh4 :

Getting a RaaS authentication error when standard Workday APIs are working fine almost always comes down to Workday’s specific security layers and how the RaaS URL is built. Even though your ServiceNow connection credentials may be valid, Workday treats custom reports differently than standard web services. Your Workday admin needs to make sure the custom report itself has "Enable as Web Service" checked, that it’s explicitly shared with your Integration System User (ISU), and that the ISU has domain permissions for the data fields inside the report. Additionally, double-check your entries on the sn_workday_hr_spke_raas_report_access_details record: the Report Name and Report Owner must match the exact string parameters in the RaaS URL path, and the User ID field should be the actual ISU username configured in your ServiceNow credentials, not a client ID or personal account.

As for the API endpoint URL shared by your customer, Workday RaaS endpoints follow a distinct path structure.
While the Workday HR Spoke typically constructs this URL dynamically behind the scenes using your connection host and the details you enter in the report access table, some custom actions or REST steps require an explicit endpoint override. If the spoke action provides an endpoint or base URL parameter, go ahead and input that full RaaS endpoint. Once your Workday team confirms the ISU permissions and web service settings, head over to your Workday Credentials record in ServiceNow and click "Get OAuth Token" to generate a fresh token before testing the call again. Hope this helps.

Hey, Thanks for sharing the info.

I cross checked the RAAS Report Access details and that is set.
one thing I am checking with Customers if they enabled as web service.

But i was checking the GEt Oauth token, I dont see it in the workday Creds record.

The passwords are set in the system property.
And then the details I have is in connection and credentials aliases.

Where can we see if it is generating it or not ?

Since your integration stores credentials in System Properties rather than standard OAuth entity profiles, it relies on basic or custom header authentication per call, which is why the "Get OAuth Token" button doesn't appear on the record. To verify whether ServiceNow is actually generating the request and see what Workday is returning, navigate to System Logs > Outbound HTTP Requests and filter for your RaaS URL path—a 401 Unauthorized error means Workday is rejecting the credentials passed from your system property, while a 403 Forbidden confirms your credentials are fine but the Integration System User lacks permission for that specific report or domain. If you need deeper technical details, you can check the ECC Queue under RESTProbe output/input records or temporarily set the system property glide.outbound_http_log.level to all so you can inspect the full HTTP headers and response payloads in real time.

I just checked the logs and could see the URL that it is trying to hit is not the correct one

Example :
This is what they shared as API endpoint
https://WDLINK/ccx/service/customreport2/client/ISUNAME/RAASReportname

And the one which system is trying to build is 

 

https://WDLINK/ccx/api/v1/client/ccx/service/customreport2/client/ISUNAME/RAASReportname