This guide walks you through connecting your ServiceNow instance through Makini Link.
Set aside about 20 minutes. You'll need your instance's address, plus either an OAuth client ID and client secret (recommended) or a ServiceNow username and password.
You'll need help from your ServiceNow administrator. Setting up an OAuth client and a service user takes admin rights on your instance. If that isn't you, send them this guide.There are two ways to sign in, on the same form.
OAuth client ID and secret (recommended). Your administrator creates an OAuth entry for Makini in ServiceNow's application registry. This is the durable option.
Username and password. A fallback for instances without an OAuth entry for Makini. These fields sit under Advanced settings on the form. They're subject to your instance's password policy and lockout, so a password change or lockout stops the connection.
Use a dedicated service user, never an admin. With the OAuth option, ServiceNow runs every call as the user the OAuth entry is bound to, with that user's roles. If that user is admin, the client ID and secret are effectively admin credentials with no multi-factor authentication. Bind it to a user made just for Makini instead, with only the roles it needs, and mark that user as web service access only so it can't sign in to the ServiceNow interface. The same advice applies if you use a username and password.
Create a ServiceNow user for Makini, for example "Makini Integration".
2.
Give it only the roles needed to read and write the records you want to connect. Not admin.
3.
Set it to web service access only.
Roles decide what the connection can see. ServiceNow hides records and fields that the user's roles don't allow, without any error. If something is missing later, the fix is usually a role for this user.
Create an OAuth entry for Makini in the application registry, with the client credentials grant enabled. The client credentials grant may need to be turned on for your instance first.
2.
Set the service user from Step 1 as the entry's OAuth application user.
3.
Give you the entry's client ID and client secret.
Treat the client secret like a password. Anyone who has it can act as the service user. Don't email it, don't put it in a chat message, don't save it in a shared document. A password manager is best.
If you're using a username and password instead, skip this step and use the service user's username and password in Step 3.
Rotating or deleting the OAuth client secret: enter the new secret on the connection
Deleting or deactivating the OAuth entry, or turning off its client credentials grant
Deactivating or locking the service user
For a username and password: the password being changed or expiring under your password policy, or the user being locked out. Enter the new password on the connection.
Removing roles from the service user doesn't break the connection, but whatever those roles allowed stops coming through.
