"Submit from this action" button not appearing in run history

[asos-martinsmith]

Severity

P2 - High (Major functionality broken)

Describe the Bug with repro steps

When I look at some run histories I see a "Submit from this action" button in the UI.

When I look at others this button is missing.

Are there some specific criteria that need to be met for this button to be shown? If so what are they?

This is similar to an issue posted here.

#8195

That one was closed due to "lack of information" but what specific information would be needed to answer this?

What is the logic used to show/hide this button?

What type of Logic App Is this happening in?

Standard (Portal)

Are you experiencing a regression?

No response

Which operating system are you using?

Windows

Did you refer to the TSG before filing this issue? https://aka.ms/lauxtsg

Yes

Workflow JSON

Screenshots or Videos

No response

Environment

Chrome 146.0.7680.165

Additional context

No response

[takyyon]

AI Triage Analysis

Component: Monitoring (Resubmit) | Priority: P2 | SKU: Standard

Relevant Code

• libs/designer-ui/src/lib/panel/panelheader/panelheader.tsx:270-279 — Renders the "Submit from this action" button; gated by canResubmit prop
• libs/designer/src/lib/ui/panel/nodeDetailsPanel/nodeDetailsPanel.tsx:247 — Passes runData?.canResubmit ?? false to the panel header
• libs/logic-apps-shared/src/utils/src/lib/models/logicAppsV2.ts:1003 — Type definition: canResubmit?: boolean on the run action result model
• libs/designer/src/lib/ui/menuItems/resubmitMenuItem.tsx — Context menu version of the same feature

Probable Root Cause

The "Submit from this action" button visibility is controlled by the canResubmit boolean property that comes from the runtime API response, not from any UX-side logic. The designer simply checks runData?.canResubmit and renders the button when it is true. The UX does not compute this value — it is returned by the Logic Apps runtime when fetching run action details.

The criteria for canResubmit are determined server-side by the runtime. Common factors that affect it include: whether the action is in a completed terminal state, whether the workflow type supports resubmission, and whether the run is a draft vs. a real execution.

Suggested Investigation

1. Compare the raw runtime API response for a run where the button appears vs. one where it does not — check the canResubmit field in both
2. This is likely a runtime behavior question rather than a UX bug — the UX faithfully renders based on the API response
3. Check if the workflow is stateful (resubmit is typically only supported for stateful Standard workflows)

Similar Issues

• submit from this action does not appear for stateful and standard logic apps #8195 — "Submit from this action does not appear" (closed as Needs More Info / stale) — same question, same root cause

---

Automated analysis by issue triage agent. May contain inaccuracies — verify before acting.
Calibration: reviewed 4 past triage(s), 0 correction(s) applied.

[asos-martinsmith]

Hi @takyyon

I had a look at the network traffic in the browser tools and can see that, indeed, in the cases that I do see the Resubmit button on the action the server is returning some elements with

"canResubmit": true

In the cases that I don't see it all of the elements being returned have

"canResubmit": false

But I'm still not clear why the runtime API would be returning false for all elements in the workflow.

• It is certainly stateful (I wouldn't be able to see the run time history in the portal if not)
• The "Resubmit" button at workflow level is enabled (but I was trying to avoid re-running a long running action in my case)
• The workflow execution is a regularly scheduled execution. Not manual execution of a draft

In the workflow where I don't see the "resubmit" button on the action I consistently don't see it in any run in any environment.

Are there any constructs used in workflows that can block this functionality and cause the API to just always return "canResubmit": false for all actions in all runs?

The workflow itself is a request triggered workflow invoked from a parent workflow. The run I was attempting to retry had definitely terminated and the response for the specific action I was looking to retry is below (but all actions in the flow had "canResubmit": false)

                        "Upload_CSV_To_SFTP": {
                            "inputsLink": {
                                "uri": "REDACTED",
                                "contentSize": 24186550
                            },
                            "outputsLink": {
                                "uri": "REDACTED",
                                "contentSize": 224
                            },
                            "canResubmit": false,
                            "startTime": "2026-03-26T00:20:41.316658Z",
                            "endTime": "2026-03-26T00:20:45.3618454Z",
                            "correlation": {
                                "actionTrackingId": "d6ba8962-42d7-4824-a103-606f44aee569",
                                "clientTrackingId": "08584271233847815280359210427CU00"
                            },
                            "status": "Failed",
                            "code": "Unauthorized"
                        }
                    },

I do see the "submit from action" button in the parent level workflow in the same app (recurrence trigger) but I was attempting to just rerun from the failed step in the stateful child workflow after the underlying authentication issue was fixed.

Is this just a limitation of Request triggered workflows? If so why does this limitation exist? Seems weird that I can replay the whole workflow but am blocked from replaying from an action. Even though it is stateful so has the history from the preceding steps.

[github-actions]

We requested more information to triage this issue. If the issue goes more than 7 days with no more information it'll be automatically closed.

[asos-martinsmith]

We requested more information to triage this issue. If the issue goes more than 7 days with no more information it'll be automatically closed.

more information was supplied.

See #8968 (comment)