Can we trigger a scheduled job from flow designer at defined time interval ?

Snehal13
Kilo Sage

I am working on a requirement as following  In my subflow I have a value that should be sent to an API for fetching status of request. This API is a 3rd party platform and returns a response body either success or failure. The API takes around 10 min to 1 hour to update the status in its systems so I need to try calling the API multiple times until the final state (in the response of API) is either Complete or Error.

 

How I can build this functionality in Flow designer

1. Trigger a scheduled job (that will call the API) from subflow in defined intervals (says every 15 min) until response from API contains New

2. Stop making new calls to the API if previous API calls returned either Complete or Error in the responseBody

1 ACCEPTED SOLUTION

Community Alums
Not applicable

Hi @Snehal13 ,

I've worked on a similar use case before, and you can definitely handle this kind of logic using Flow Designer and Scheduled Flows or a combination of Flow + Script.

Here’s one way to approach it:

1. Store the status and a unique identifier:

When your subflow first triggers the API call, store the request identifier and the current status (like "New") in a custom table or on the record you're tracking. This will help keep track of whether further polling is needed.

2. Use a Scheduled Flow:

Create a Scheduled Flow that runs every 15 minutes and checks for requests where the status is still "New". In that flow:

  • Call the API using the request ID.

  • Parse the response.

  • If the response is still "New", do nothing — the flow will try again in the next run.

  • If the response is "Complete" or "Error", update the status and stop further attempts (since the Scheduled Flow will skip records that are no longer "New").

Optional – Limit polling:

You can also add a “retry count” or a “last polled time” field, just to make sure you’re not hitting the API too aggressively or endlessly in case something goes wrong.

Alternate Option – Scripted Wait Logic (not in Flow Designer):

If you're okay mixing in a Scripted Flow Action, you could use a loop with gs.sleep() and a condition to keep checking the status. But honestly, that’s not a good idea for long waits like 10 mins to 1 hour — it ties up system resources. Scheduled Flows are safer and cleaner in this case

View solution in original post

2 REPLIES 2

Community Alums
Not applicable

Hi @Snehal13 ,

I've worked on a similar use case before, and you can definitely handle this kind of logic using Flow Designer and Scheduled Flows or a combination of Flow + Script.

Here’s one way to approach it:

1. Store the status and a unique identifier:

When your subflow first triggers the API call, store the request identifier and the current status (like "New") in a custom table or on the record you're tracking. This will help keep track of whether further polling is needed.

2. Use a Scheduled Flow:

Create a Scheduled Flow that runs every 15 minutes and checks for requests where the status is still "New". In that flow:

  • Call the API using the request ID.

  • Parse the response.

  • If the response is still "New", do nothing — the flow will try again in the next run.

  • If the response is "Complete" or "Error", update the status and stop further attempts (since the Scheduled Flow will skip records that are no longer "New").

Optional – Limit polling:

You can also add a “retry count” or a “last polled time” field, just to make sure you’re not hitting the API too aggressively or endlessly in case something goes wrong.

Alternate Option – Scripted Wait Logic (not in Flow Designer):

If you're okay mixing in a Scripted Flow Action, you could use a loop with gs.sleep() and a condition to keep checking the status. But honestly, that’s not a good idea for long waits like 10 mins to 1 hour — it ties up system resources. Scheduled Flows are safer and cleaner in this case

SumanthDosapati
Mega Sage
Mega Sage

@Snehal13 

To call a scheduled job from Flow, you can create a custom action.

Check this link in which it was built.

 

Accept the solution and mark as helpful if it does, to benefit future readers.
Regards,
Sumanth