PowerLeap Logo

Copilot Studio Friction

Get notified when this record changes

One email when the status or the fix changes — double opt-in, no tracking, unsubscribe in every email.

Agent flow fails with FlowActionTimedOut after about 100 seconds

Opensince 8 July 2026

Last verified

Details & related

Assessment

Confidence
Confirmed officialConfirmed by Microsoft documentation or an official statement.
Severity
Blocking
Typical time lost
Hours

Identification

Agent flowsAll channels

Verification & changes

  1. Verified

    Doc check by human: Official docs and CAT blog post re-read during seed migration; the 100-second limit is still documented.

  2. Change

    Provisionally approved by the Product Owner; external LLM quality review pending.

  3. Change

    Initial record created from the seed dossier (migration wave 1 reference set).

Related

Are you in the right place?

  • Your agent calls an agent flow, and the run fails with error code FlowActionTimedOut.
  • The failure appears when the flow runs for roughly 100 seconds or more.
  • The same flow succeeds when its run is short.
  • The flow contains slow work, such as approvals, long loops, or slow external systems.

If instead the flow fails right away with FlowActionBadRequest → a schema or type mismatch (record planned). If instead the agent says "No output was received from flow" → a branch misses its response (record planned).

What's happening

Copilot Studio waits a limited time for an agent flow to answer. The official documentation sets a 100-second action limit. In a community thread, Microsoft describes it as a roughly two-minute timeout. When your flow needs longer, the agent gives up and reports FlowActionTimedOut. The flow itself may even finish later — but the conversation has already moved on. Picture a hotline that hangs up after 100 seconds on hold — whatever happens afterwards, the caller is gone. Anything that waits for a person, such as an approval, can never fit into this window.

For technicians

Official guidance: actions placed after the "Respond to the agent" step "continue to run up to the flow run duration limit of 30 days."

Human-in-the-loop features pause the flow run until a person responds. Microsoft's Copilot Studio CAT blog states there is no way to call them inside a synchronous conversation. They work only in autonomous scenarios or after restructuring the flow. Express mode (preview) speeds up runs but forbids Delay and webhook actions and caps a run at 100 actions.

How to fix it

Solution 1

Official workaround

Split the flow at "Respond to the agent"

  1. Open the agent flow in the flow designer.
  2. Identify the actions that produce the answer the agent needs right now.
  3. Place the "Respond to the agent" action directly after those fast actions.
  4. Move every slow action behind "Respond to the agent".

✅ You should now see: the agent receives its answer within the 100-second limit, while the moved actions keep running for up to 30 days.

  1. Save the flow.

Solution 2

Official workaround

Use the async continuation pattern

Use this when the user needs the slow part's final result, or for approvals mid-flow. The full recipe is the async continuation pattern; in short:

  1. Pass System.Conversation.Id from the topic into the flow as an input.
  2. Respond fast, as in the split solution above.
  3. After the slow part, call the agent back with the "Execute Agent" action of the Copilot Studio connector.
  4. Send the saved conversation ID along with the callback.
  5. Extend the agent's instructions to handle both the first call and the callback.

✅ You should now see: the agent reports the final result, correlated to the original conversation via the ID.

Solution 3

Official workaround

Speed the flow up with Express mode

  1. Check the Express mode limits first: no Delay or webhook actions, at most 100 actions per run.
  2. Confirm your flow stays within those limits.
  3. Enable Express mode for the agent flow — it is a preview feature, so expect changes.

✅ You should now see: shorter run times in the flow's run history.

  1. Retest the slow case through the agent.

Check that it worked

Trigger the flow through the agent with a realistic slow case, in the published channel your users use. Expected: the agent answers within the timeout, and the run shows as succeeded in Power Automate's run history.

If it didn't work

  • The fast part is still too slow. Move more actions behind "Respond to the agent". Reduce the remaining work before the response.
  • You changed the flow's inputs or outputs. The agent then calls a stale schema. Refresh the tool configuration in the topic (see FlowActionBadRequest, record planned).
  • The channel still runs your old agent version. Publish and propagation delay is suspect number one after any change. See Teams answers with an old version of your agent.
  • A person is in the loop. Approvals pause the run; no split makes them synchronous. Move to the async continuation pattern.

Prevent it next time

  • Treat the 100-second budget as a design constraint from day one of every agent flow.
  • Decide on the async continuation pattern as soon as a human approval enters the design.
  • Keep slow work behind "Respond to the agent" by default, not as an afterthought.

Evidence

  • Official documentationlearn.microsoft.com

    The official doc sets a 100-second action limit; actions after 'Respond to the agent' run up to the 30-day flow run duration limit.

  • Official documentationlearn.microsoft.com

    Express mode (preview) forbids Delay and webhook actions and caps a flow run at 100 actions.

  • Microsoft statementmicrosoft.github.io

    Microsoft's CAT team specifies the async continuation pattern and states human-in-the-loop features cannot run in a synchronous conversation.