You need your bot to wait for a button, form field, or dialog to appear before interacting with it — but also need to know whether something is on screen without throwing an error if it isn’t. UiPath gives you three activities that all sound like they do the same thing: Find Element, Element Exists, and Check App State. Using the wrong one leads to either bots that crash on missing elements, or bots that silently proceed when they shouldn’t.

Understand how each activity waits, times out, and reports its result, so you can build UI automations that fail predictably instead of randomly.

Solution

Find Element Activity

Use Find Element when you need to actively locate a UI element and get a reference to it (a UiElement) so you can act on it or inspect its properties.

Dependencies UiPath.UIAutomation.Activities

1. Activity: Find Element Activity.
2. Output type: A UiElement object.
3. Behavior: Waits up to the configured timeout, then throws an exception if the element isn’t found.

Element Exists Activity

Use Element Exists when you just need a yes/no answer about whether something is currently on screen, without stopping your workflow if it’s not.

Dependencies UiPath.UIAutomation.Activities

1. Activity: Element Exists Activity.
2. Output type: A Boolean (True/False).
3. Behavior: Checks once (or briefly), never throws an exception — it just returns False if not found.

Check App State Activity

Use Check App State (part of Modern activities) when you want your bot to wait for a specific condition — element exists, doesn’t exist, is enabled, is visible — before moving forward, ideally combined with a trigger-based wait.

Dependencies UiPath.UIAutomation.Activities (Modern)

1. Activity: Check App State Activity.
2. Output type: Boolean condition result, often used to drive a retry scope or conditional branch.
3. Behavior: Actively monitors for the target state to become true, within a timeout, without repeatedly polling in a way that breaks your workflow logic.

Wait Behavior

Activity	Waits for element?
Find Element	Yes, up to timeout, then throws
Element Exists	Minimal/no real wait — quick check
Check App State	Yes, actively waits for the condition to become true

This is the single biggest source of confusion: Element Exists is not a substitute for waiting. If the element genuinely takes a few seconds to load, Element Exists can return False just because it checked too early.

Timeout

• Find Element: Has a configurable timeout (default ~30s); throws SelectorNotFoundException if exceeded.
• Element Exists: Has a much shorter effective check, since it’s designed for an instant “is it there right now” answer, not a wait-and-retry.
• Check App State: Has a timeout too, but it’s built for waiting on a state to change, not just presence — more suited to dynamic apps where load times vary.

Output Type

• Find Element → UiElement (you get the actual element to click, type into, or read from).
• Element Exists → Boolean.
• Check App State → Boolean condition result, typically feeding into an If or a Retry Scope.

Exceptions

• Find Element throws if the element isn’t found within the timeout — good for cases where the element is required for the workflow to continue.
• Element Exists never throws for a missing element — perfect for conditional logic like “if this popup exists, close it.”
• Check App State is designed to be exception-safe when used correctly, since its whole purpose is checking state rather than assuming it.

Performance

• Element Exists is the fastest for a one-time check since it doesn’t retry aggressively.
• Find Element can be slower because it actively retries until the timeout or success.
• Check App State sits in between — it’s built to be efficient while still waiting for genuine state changes, and is generally recommended over repeated Element Exists checks in a loop.

Modern vs Classic Activities

Check App State is a Modern activity, part of UiPath’s newer, more efficient UI automation stack. If you’re building new workflows, Microsoft/UiPath’s own guidance favors Modern activities where available — they tend to be more reliable with dynamic, modern web apps. Find Element and Element Exists exist in both Classic and Modern flavors, so make sure you know which one you’ve dragged onto the canvas, since their underlying selector engines differ slightly.

Real-World Scenarios

• Find Element: You need to click a “Submit” button that must exist — if it’s not there, something’s wrong and the bot should stop.
• Element Exists: Checking if an optional “Cookie Consent” popup is present so you can dismiss it, without crashing if it’s simply not shown that session.
• Check App State: Waiting for a modern single-page web app to finish loading a dashboard widget before reading data from it, where load time varies between 2 and 15 seconds.

💡 Best Practices

• Use Find Element only when the element is mandatory for the next step — let it throw, and handle that with a Try Catch or Retry Scope.
• Use Element Exists for optional, conditional UI elements — combine with an If activity.
• Use Check App State for dynamic, slow-loading modern applications instead of looping Element Exists checks manually.
• Don’t use Element Exists in a manual while loop to “wait” for something — that’s exactly what Check App State or Find Element’s timeout already does for you.
• Always set realistic timeouts based on actual application load times, not UiPath’s defaults, especially for slow internal enterprise apps.

Rule of thumb: need the element itself → Find Element. Need a quick yes/no → Element Exists. Need to wait for a state to become true on a modern app → Check App State.