Lookup Action in Flow Fails Randomly After Modifying Custom Table Default View

[E555]

After editing the Default View of a custom table in ServiceNow (removing certain fields), I noticed that those fields can no longer be referenced in the "Look Up" action within a Flow.

I would understand if the lookup failed 100% of the time, but in my case, it sometimes succeeds and sometimes fails—roughly a 50/50 chance. Even with the same values and conditions, the results seem to be random.

Has anyone encountered a similar issue? Any insights would be greatly appreciated.

[KKM]

Hi E555,

Yes, this behavior in ServiceNow can be quite frustrating, and it often stems from caching issues, indexing inconsistencies, or how the Flow Designer interacts with the table schema.

Here are a few possible reasons for the inconsistent lookup behavior:

1. Cache Issues
When you modify a table’s Default View by removing fields, ServiceNow might still have some cached references to the old configuration.
Try clearing the system cache by navigating to System Diagnostics > Cache > Flush All or entering cache.do in the navigation filter.
2. Field Visibility in Flow Designer
Even though fields are removed from the Default View, they still exist in the table. However, Flow Designer may not always correctly resolve them if they are not actively used in a view.
Check if the fields are still present in the table schema (sys_dictionary) and accessible via the API.
3. Indexing Issues
If the removed fields were part of a lookup key or had an index, ServiceNow might be struggling to efficiently retrieve them.
Try rebuilding the index on the affected fields by navigating to System Definition > Tables & Columns, selecting the field, and saving it again.
4. ACLs or Security Constraints
If your user account or Flow Designer is running under different permissions, it might not always have access to the fields.
Check the Access Controls (ACLs) for the table (sys_security_acl).
5. Flow Designer Execution Order
ServiceNow's Flow Designer sometimes executes actions in a non-deterministic manner if there are parallel executions.
Add a short delay (Wait action) before the lookup to ensure any table modifications are fully recognized.
6. Debugging with Logs
You can check the System Logs (syslog_transaction, sys_flow_context, sys_flow_log) to see if there are any errors when the lookup fails.
If none of these solve the issue, try re-adding the fields temporarily and testing again. If the lookup stabilizes, then removing the fields may indeed be disrupting the lookup mechanism.

This should solve your issue!

Kindly mark it as "Accepted Solution"/"helpful", as it resolves your query. Please press like button for the resolution provided.

With Regards,
Krishna Kumar M - Talk with AIT3ch
LinkedIn: https://www.linkedin.com/in/mkrishnak4/
YouTube: https://www.youtube.com/@KrishAIT3CH
Topmate: https://topmate.io/mkrishnak4 [ Connect for 1-1 Session]