Hi ​@benjamin.edalatian.schahriari,

The short answer is in A360 there isn’t an official switch to force HTML technology in the Recorder. The old v11 Object Cloning → Select Technology → HTML model is gone; in A360 the Capture action (which replaced Object Cloning) auto‑detects the target technology, and the only technologies you can explicitly force today are accessibility frameworks like MSAA/UIA, not HTML. 
 

That said, there are reliable ways to bias the Recorder toward HTML/DOM capture and avoid image/accessibility fallbacks:

1. Start with a supported browser and extension.

• Use Chrome or Edge (Chromium), and make sure the Automation Anywhere browser extension is installed and enabled. Without it, Recorder often falls back to non‑HTML techniques. The official doc explicitly calls out enabling the plugin for browser automation. 
• If you see sluggish or inconsistent behavior on local settings pages, AA also recommends specific extension settings (e.g., Allow access to file URLs). 

2. Open the site with the Browser package, then capture

Launch your web app using Browser → Open, and then use Recorder → Capture against that tab. Keeping a managed browser session tends to keep Recorder working via the DOM (HTML) through the extension rather than through accessibility/image layers. (Browser package scope and supported browsers documented here.) 

3. Avoid Capture using specific technology for web pages

That dropdown is there mainly to force MSAA/UIA/UIA(COM) for desktop apps that don’t expose good properties. If you select one of those on a web page, you’ll move away from HTML. Leave it at the default (auto) for web, so the DOM path (DOMXPath/DOMX) stays primary. 

4. Edge IE‑mode exception

If you must automate legacy IE‑mode content in Edge, AA states the objects are captured using HTML technology in that mode, once enabled. That’s one of the few places the docs explicitly mention HTML capture today. 

5. Prefer stable DOM properties

• After you capture, edit the object properties to rely on DOMXPath (DOMX) or stable HTML attributes (innerText/value) rather than brittle indexes. Community guidance recommends DOMXPath‑only whenever possible for Recorder: Capture. 
• For dynamic tables/lists, build dynamic DOMX with variables or conditions instead of hardcoded positions (examples below). Community posts show this pattern for changing rows/paths. 

6. For embedded web (CEF) or stubborn UIs

If you’re dealing with a CEF UI (Chromium Embedded Framework) where HTML capture is flaky, consider Browser → Run JavaScript / Call a JavaScript function (when applicable) or fall back to targeted UIA where appropriate. The Browser package documents these options