ServiceNow Things to Know 60: Avoid using Table API for Create/Update Integrations

[PrashantLearnIT]

When designing Integration Solutions for customers which require external systems to create or update records in ServiceNow you should avoid using ServiceNow's Table API for those operations.

Table API might seem like the quickest and easiest solution, but giving this to an external system can cause issues because Table API is able to bypass several UI-based ServiceNow controls - For example:

- Table API won't validate references or choices - which means that the External system can insert broken data into the target record.

- Table API is blind to UI processes on the target record - any UI-based controls (like Client Scripts, UI Policies, UI Actions for State flows etc) that the customer might want to have - like not allowing an invalid assignee for an assignment group or not allowing an invalid Impact/Urgency/Priority structure - will be unable to be enforced via Table API.

- Once an integrator understands they have Table API to one table, they can use it elsewhere - If you give the integration account a role or roles that allows write access to tables or records other than the intended target (for example itil role) then it means that the integration system could potentially create a call that creates or edits records to which it is not permitted.  If you MUST do a table API integration, spend a lot of time designing appropriate ACLs and never give the integration account OOTB roles like "itil" and especially not "admin".

-------

I've edited this article to add some content that can be shared with customers or third party integrators to help them understand the impacts of using Table API if you ever need to push back on a Table API-related integration:

Avoiding use of Table API for database create or update transactions.

One thing that we often see third party developers do when integrating with ServiceNow is use the most basic integration method that they find when researching ServiceNow which is a thing called “table API” which is a prominent REST API that allows direct create/update/read access to ServiceNow Database tables.

Using Table API is an anti-pattern and a poor practice for working with ServiceNow for a few reasons:

• Roles can allow excessive access: Often integrators will ask that the service account they are given is granted a role called “itil” which is equivalent to an agent’s access which can grant excessive access to an instance which doesn’t align to the security “Principle of Least Privilege” – roles and access controls should be specifically crafted for service accounts and avoid using OOTB roles to avoid unexpectedly applying excessive privilege to a service account.
• Bypass ServiceNow logic and processes: Using Table API to create or update records ignores almost all controls or validations on that can stop “bad” data from being written to the database.  If the sending system sends an invalid value or something that bypasses process controls this can cause issues in the target instance for things like governance or security (like SQL injection and cross-site scripting)
• Requires the sending system to know all ServiceNow data structures:  because Table API doesn’t have any staging or transformation logic, it means that the sending system needs to know about the current valid data state for the target system at all times – as ServiceNow systems change quite dynamically it can be difficult for the external system to keep an accurate representation of the target system. 
• No errors for invalid data: related to the above points, if the sending system doesn’t send accurate data Table API will simply allow it without sending back an error, so it’s possible to not identify corruption if it occurs.

Alternatives to Table API:

Most alternatives to Table API for writing to ServiceNow require some level of development or configuration to be done on the receiving ServiceNow instance.  The two most suitable alternatives are:

Import Set API – this makes use of ServiceNow’s native Extract/Transform/Load system (import sets and transform maps).  It gives the ServiceNow admin greater control over data validation to ensure compatibility with the target process implemented in their instance.

Scripted REST API – This is a more advanced option but gives a high degree of flexibility to create custom endpoints on the target system to receive and process payloads in the best possible way.  Transformation can be done in code or can use any other method available in ServiceNow such as scripted calls to Flow Designer or even Import Sets.

If my content helped you in anyway, please mark this content as BOOKMARK, SUBSCRIBE & HELPFUL

Best Regards,

Prashant Kumar (LearnIT)

YouTube Channel LearnIT: https://www.youtube.com/@learnitwithprashant

Blog LearnIT: https://medium.com/@LearnITbyPrashant

Prashant Kumar LinkedIn: https://www.linkedin.com/in/learnitbyprashant/

ServiceNow Community Prashant Kumar - https://www.servicenow.com/community/user/viewprofilepage/user-id/19635