Power Platform Community Forum Thread Details

Hi everyone,

I am new to Power Automate and have already run into a few issues.

I am trying to create a flow that fills out the same web form using data from an Excel table. Everything was going well until I started working with web form filling.

The first issue is that the target web page appears to use an older HTML structure (see attached screenshots). When I try to capture a radio button, Power Automate identifies a <span> element instead. Because of this, I'm wondering whether I should use Click link on web page rather than Select radio button.

The second issue involves a drop-down list. When I capture the control, Power Automate identifies it as an input element rather than a select element. The available options are stored separately as <li> elements. Since these options may change over time, I'm not sure what the best approach is for selecting the correct value dynamically.

Has anyone encountered a similar situation or can suggest the best way to handle these controls in Power Automate?

P.S. On each sreenshot there are how it looks like on a web page, in code and how see it Power Automate Desktop

Categories:

Power Automate Desktop

Building flows

Using connectors

You can try the following approach. From your screenshots, it looks like the page is built with a modern JavaScript framework (the el-radio, el-radio-group, el-select classes are commonly associated with Element UI/Element Plus). These controls often don't use native HTML <input type="radio"> or <select> elements in the way Power Automate Desktop expects.

For the radio button:

If PAD is capturing the clickable <span> instead of the radio input, that's normal for many JavaScript frameworks.

Instead of Select radio button, use Click UI element in window/web page (or Click link on web page if that's what PAD captured).

The visible <span> usually triggers the underlying radio selection, so clicking it is often the most reliable approach.

After clicking, you can optionally verify the selection by checking whether the element's class changes to something like is-checked.

For the drop-down:

Since PAD detects an input rather than a native <select>, the control is likely a custom JavaScript dropdown.

A common pattern is:

1. Click the dropdown/input to open the list.

2. Wait for the list (<li> elements) to appear.

3. Use Find elements or Get details of element to retrieve the available <li> items.

4. Loop through the items and click the one whose displayed text matches the value from Excel.

Avoid selecting by position (index), since the options may change over time.

A few additional tips:

Add a short Wait for web page content or Wait for element before interacting with dynamic controls.

If UI element selectors become unreliable, consider editing the selector to rely on stable attributes such as id, name, aria-label, or visible text instead of deeply nested DOM paths.

If the page is heavily JavaScript-driven, enabling Simulate action (when supported) or falling back to physical clicks can sometimes improve reliability.

Overall, based on your screenshots, I would not use the Select radio button or Select option from drop-down list actions. Treat both controls as custom UI components and interact with them using click actions plus dynamic element matching. This approach is generally the most reliable for Element UI–based web applications.