Learn browser automation one small step at a time.

Automation Studio separates what to do, how and where to run it, and when to run it. Keeping these jobs separate makes the same Workflow reusable.

Example

This separation means you can reuse the same Workflow later with a different Profile group or different execution settings without making a second copy of the Workflow.

This first exercise is intentionally simple. The goal is to learn the Studio flow, not to build a complex project.

An Action is one thing the browser should do. Most Workflows are simply a sequence of Actions plus conditions and error handling.

Type vs Fill

Use Type when the website cares about keyboard events or when you want behavior closer to a person typing. Use Fill when you want to replace the current field value directly and the website accepts normal input/change events.

Test actions as you build

When possible, test a new Action immediately. If Step 4 does not work, fix Step 4 before adding Step 5. This keeps the source of a problem obvious.

The Recorder is the fastest way to start when you already know how to perform a task manually. Start recording, perform the task, then clean up the recorded steps.

1. Start Recording. Open the page where the process begins.
2. Perform the task normally. Click, type and navigate as you usually would.
3. Stop Recording. Return to the generated steps.
4. Remove noise. Delete accidental clicks, unnecessary scrolling or duplicate actions.
5. Review locators. Prefer stable element clues over fragile page positions.
6. Add verification. Decide what result proves an important Action succeeded.
7. Test from the middle. Use Run from here or step testing while refining a section.

A locator tells the browser which element you mean. The best locator describes the element clearly enough that the browser can find it again even when the page changes slightly.

Resilient locators and healing

Automation Studio can keep more than one clue for an element: the primary locator, alternatives and a semantic fingerprint such as tag, role, label, text and stable attributes. If the original locator no longer matches, the Locator Engine can inspect safe alternatives and relocate the element when confidence is high enough.

Practical locator rules

• Prefer an element identity over its screen position.
• Prefer unique, meaningful attributes over long generated CSS paths.
• Use alternatives for important actions.
• Re-test locators after a website redesign.
• Use Target Guard information when debugging a wrong or ambiguous match.

A Social Browser Profile keeps its own browser state. Automation lets you reuse the same Workflow without copying the Workflow for every Profile.

Depending on the Automation settings, you can target a single Profile, multiple Profiles, all matching Profiles, or groups/tags. The Task Engine creates concrete SubTasks for the actual Profile runs and aggregates their progress into the parent Task.

Why this matters

If the work is identical but the browser session is different, keep one Workflow and change the target selection in the Automation. This reduces duplicate setup and makes maintenance easier.

A variable is a value that can change without changing the Workflow steps. Use variables for URLs, names, search terms, dates, messages and other input that should be supplied at run time.

productUrl = "https://example.com/item/123" customerName = "Alex" message = "Your report is ready"

Open {{productUrl}} Type "Hello {{customerName}}" Type "{{message}}"

Use variables when…

• the steps stay the same but the input changes;
• different Tasks should reuse one Workflow;
• a Profile or data source provides a different value;
• you want a clear configuration area instead of editing step text.

A fixed sequence works only when every page behaves the same way. Conditions let the Workflow ask a question before deciding what to do.

IF optional popup exists Click "Close" ELSE Continue

The Unified Condition Engine can support patterns such as element exists, visible state, text match, URL state, attribute values, wait-until checks and assertions. Conditions can be combined with AND/OR logic when several facts must be checked together.

Example: optional dialog

1. Check whether the dialog is visible.
2. If yes, click its safe close button.
3. If no, skip the close step.
4. Continue with the normal Workflow.

This is one of the most important ideas in reliable automation. A click can be delivered successfully while the website rejects the result, delays it, changes a different element or never finishes the requested operation.

Common outcome states

Verification examples

Automation Studio separates how the input is delivered from how natural or direct the interaction should feel.

Interaction style

Drivers

Recommended for most users: start with Auto. Explicit drivers are useful when testing, debugging or when you know a site behaves better with a particular input path.

The Automation entity is where you define execution policy. The exact options can vary by action and runtime, but the important ideas are consistent.

Example: 50 Profiles, five at a time

Select your 50 target Profiles and set concurrency to 5. The Task Engine can create the Profile SubTasks and dispatch them in controlled groups rather than opening everything at once.

Ghost Profiles created for a Task can share the same Ghost runtime process while keeping separate isolated partitions/sessions. Process sharing improves efficiency without turning those sessions into one shared browser identity.

Reliable automation is not only the happy path. A Workflow should also define what to do when an error, timeout or uncertain result occurs.

Main steps ↓ onErrorSteps onTimeoutSteps onInconclusiveSteps ↓ finallySteps

Example

Try to submit the form If error → capture diagnostics If timeout → record timeout reason If inconclusive → send to review Finally → perform safe cleanup

Use finally for cleanup that should happen whether the main path succeeds or fails, such as closing a temporary tab or writing a final log entry.

Long-running automation should not always restart from Step 1 after an application restart or interruption. Checkpoints record safe progress so a Workflow can resume from a known point.

Checkpoint data should match the Workflow definition it belongs to. If the Workflow changes, the system can use a Workflow hash/checkpoint contract to avoid resuming into an incompatible sequence.

Some situations should not be decided automatically. If the browser delivered an action but cannot prove the final result, or if a target is ambiguous, a Review Item can pause the decision and let a person choose what happens next.

Important reliability features

Idempotency in plain language

If an operation has already been completed for the same resource, repeating it may be unnecessary or harmful. An idempotency key gives the runtime a way to recognize the logical operation, not just the individual click that caused it.

Once a Workflow works reliably and the Automation targets are correct, create a Task to control when the combination runs.

• Run manually.
• Run once at a chosen time.
• Repeat on an interval.
• Use calendar-style schedules.
• Enable or disable a Task without deleting it.
• Choose how overlapping runs should behave.

Before scheduling

1. Run the Workflow manually.
2. Test it on one Profile.
3. Test the final Automation target set.
4. Confirm verification and error branches.
5. Only then turn on a recurring schedule.

Good debugging starts with evidence, not guessing. Automation Studio exposes structured information so you can identify whether the problem came from navigation, the locator, actionability, input delivery, verification, a frame, a timeout or the site itself.

A practical debugging order

1. Copy the exact error. Do not rely on a screenshot when text diagnostics are available.
2. Check the final URL. Make sure the Workflow is on the page you expect.
3. Check locator diagnostics. Was the intended element found? Was it ambiguous?
4. Check actionability. Was it visible, enabled, stable and able to receive events?
5. Check delivery. Which driver was used? Was input delivered?
6. Check verification. Did the action execute but the effect stay inconclusive?
7. Check frame/window context. Was the element inside an iframe, nested frame, popup or another tab?
8. Check the website manually. A site change or slow backend may be the real cause.

Use these as patterns. Replace the sample website and data with systems you are authorized to automate.

IF popup close button exists Click close ELSE Continue

Which feature should I use?

Glossary

Action

One browser operation inside a Workflow.

Workflow

The ordered logic that describes what should happen.

Automation

The execution policy: targets, windows, concurrency, timeouts and related settings.

Task

The object that binds one Workflow and one Automation and controls manual/scheduled execution.

SubTask

A concrete persisted unit of work created from a Task, commonly tied to a Profile/resource.

Profile

A persistent isolated browser environment.

Ghost Profile

A temporary isolated execution Profile.

Locator

The rule or bundle of clues used to identify a page element.

Verification

The check that determines whether the expected effect happened.

Evidence

Structured before/after information, diagnostics and optional screenshots used to understand an outcome.

Idempotency

A way to recognize the same logical operation so a repeat does not accidentally create a duplicate effect.

Circuit Breaker

A protection that pauses a failing site/action path when recent failures indicate a broader issue.

Beginner checklist

• I can explain Workflow vs Automation vs Task.
• I built a short Workflow manually.
• I tested it in one visible Profile.
• I know how to use Recorder and clean up recorded steps.
• I can identify a page element with a stable locator.
• I can add a variable and a simple condition.
• I understand why important actions need verification.
• I know where to copy logs and errors when something fails.

Advanced checklist

• I use explicit verification for important side effects.
• I understand no-replay behavior after uncertain delivery.
• I can configure concurrency and timeouts intentionally.
• I know when to use persistent vs Ghost Profiles.
• I use error/timeout/inconclusive/finally branches where needed.
• I can use checkpoints for long workflows.
• I understand Review Center decisions.
• I can interpret locator, actionability, driver and verification diagnostics.