Machine to Machine CLient Credential Grant type failure

AryanSingh
Tera Contributor

Hi Experts,

I would like to seek your guidance on a client requirement.

The client wants to fetch Incident data for a specific assignment group from ServiceNow and display it on a SharePoint Dashboard.

I would appreciate your support on the below points:

  1. What is the recommended way to provide the client access to fetch Incident details from ServiceNow to SharePoint?
  2. Should this be implemented using the Machine-to-Machine (Client Credentials Grant Type) approach?
  3. If yes, could you please help me understand:
    • What configurations are required in ServiceNow?
    • What details/information need to be shared with the client for their integration?

I tried exploring the Machine-to-Machine / Client Credentials Grant Type option, but I am currently unable to test it properly.

KB - https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB2624687

If anyone has worked on a similar use case, please share your suggestions or guidance.

Thank you in advance for your support.

1 REPLY 1

kmohammed
Tera Guru

Hi Aryan,

 

Yes, Machine-to-Machine with the Client Credentials grant type is the right approach here. This is a server-to-server integration with no user signing in, so you should not use the password grant, basic authentication with a personal account, or an admin account.

 

Configuration in ServiceNow:

 

1. Create a dedicated integration user for this integration only. Keep it active, give it only the roles needed to read incidents, and do not give it admin.

2. Register an OAuth application for the external client and enable the client credentials grant type. This gives you a client ID and a client secret.

3. Confirm the integration user can read the incident table through ACLs. If the user has no incident read access, the API call will return no records or an access error even with a valid token, and the assignment-group filter alone does not grant access.

4. Test the token flow first, before testing the dashboard: POST to https://<your-instance>/oauth_token.do with grant_type=client_credentials, client_id, and client_secret. You should receive an access token.

5. Then call the Table API with that token, for example: GET https://<your-instance>/api/now/table/incident?sysparm_query=assignment_group=<group sys_id>&sysparm_fields=number,short_description,state,priority,assignment_group,opened_at&sysparm_limit=100

 

Details to share with the client, through a secure channel:

- The instance URL

- The client ID and client secret

- The token endpoint: https://<your-instance>/oauth_token.do

- The Table API URL, the assignment-group query, and the field list above

 

Important: the client secret and the token call must stay server-side, for example in the SharePoint backend service or integration layer that feeds the dashboard. Do not embed the secret in a browser page or SharePoint web part, where anyone viewing the page could see it.

 

Common reasons testing fails at this stage are an inactive OAuth application, a locked or inactive integration user, a missing incident role or ACL, or posting to the wrong token endpoint or with the wrong grant_type. Check those in that order before changing the dashboard design.