How can we optimize IntegrationHub executions for an external incident integration?

[tabrez ahmed]

Hi ServiceNow Community,

I am looking for some guidance from IntegrationHub/Flow Designer experts regarding an integration we currently have between ServiceNow and an external incident management system (XYZ).

We are seeing a high number of IntegrationHub executions, and we are trying to understand the best way to optimize the existing implementation.

Current implementation

Our current setup is approximately:

• A scheduled Flow runs every 10 minutes.
• The Flow calls the XYZ Incident REST API.
• There are around 50 open incidents in XYZ.
• The Flow retrieves these incidents and processes them one by one.
• For each incident, around 6 actions/subflows are executed for things such as incident updates, comments, attachments, etc.
• Even if only a few incidents are actually modified, the current implementation processes all the incidents.

For example:

50 incidents × ~6 executions = ~300 executions every 10 minutes.

If this continues for a month:

6 × 24 × 30 × 300 = ~1,296,000 executions/month.

Proposed optimization

One idea being discussed is to make the integration more incremental.

Instead of retrieving all open incidents every 10 minutes, we could:

1. Store the last successful integration run timestamp.
2. Query XYZ for only incidents that have been modified since the previous successful run.
3. Process only those returned incidents.

For example:

50 open incidents
       ↓
Only 5 incidents modified
       ↓
Retrieve only those 5
       ↓
Process those 5 incidents

This could potentially reduce:

Current:
50 × 6 = ~300 executions

Proposed:
5 × 6 = ~30 executions

There is also a suggestion to simplify the Flow Designer structure by reducing multiple nested subflows/actions and moving some processing into a reusable Action.

What I would like advice on

I am not very experienced with IntegrationHub optimization, so I would really appreciate guidance on the correct/recommended ServiceNow architecture for this scenario.

Specifically:

1. What is the recommended approach in ServiceNow to process only records that have changed since the previous integration run?
2. If the external API supports a modified/updated date field, is it a good approach to pass the last successful run timestamp as a filter in the REST API request?
3. Where is the best place to store the last successful integration timestamp?
   For example, System Property, custom table, Integration record, or some other recommended approach?
4. Is it a good practice to consolidate multiple nested subflows/actions into a single reusable Action to reduce IntegrationHub execution consumption?
5. Are there any ServiceNow best practices for optimizing IntegrationHub execution usage in scheduled integrations?
6. What should we consider regarding:
   • Pagination
   • Duplicate processing
   • Error handling
   • Retry mechanism
   • Failed integration runs
   • Timestamp/record gaps between two runs
7. Is there a better architecture than the approach described above?

Current vs proposed

  Current Proposed

Incidents retrieved	~50	Only modified incidents
Executions per 10 min	~300	Potentially ~7–30
Monthly executions	~1.29M	Potentially ~30K
Processing	All incidents	Only changed incidents

These numbers are based on our current assumptions and are being used only to illustrate the problem.

I would really appreciate any recommendations, best practices, or real-world implementation examples from anyone who has worked on optimizing IntegrationHub/Flow Designer integrations.

Thanks in advance!

[tabrez ahmed]

@Ankur Bawiskar  : Would appreciate your thoughts on the IntegrationHub execution optimization approach described above.

[tabrez ahmed]

@Ravi Gaurav : Any recommendations on the Flow Designer/IntegrationHub architecture would be highly appreciated