Shiva

sonal please let me know if this helps

I would generally recommend an event-driven approach over direct API calls for distributed cache environments because it decouples systems, scales better under load, and provides more resilient cache synchronization. For simpler integrations or cache invalidation use cases, REST APIs are often the most straightforward solution.

Here is my perspective No. APIs are the simplest and most common approach, but Workato can also integrate cache distribution through: Event-driven messaging ( Pub/Sub(previous name) event stream) Database synchronization Custom SDK connectors Webhooks Workato Datatables (for lightweight caching scenarios)

Lets connect tomorrow because I am not seeing this in my workspace

Chinmay You should be able to access it now. Those errors were temporary issues.

Hi dkuroda Good morning I hope you are doing well This happens because switching from polling to a real-time trigger changes how ServiceNow needs to authorize Workato. Real-time triggers work by creating a Business Rule record in the sys_script table — that Business Rule is what fires the webhook to Workato whenever a new incident is created. Your connected user needs explicit access control on that table for this to work, which polling never required. The exact permissions you need, per Workato's current docs: The account used for your ServiceNow connection must have a role with these access control rules: Table Type Operation Name BR record read sys_script / sys_script.* BR record write sys_script / sys_script.* BR record create sys_script BR record delete sys_script