User Defined

User Defined is the in-test face of a User-Defined template. When you drag a template into a test, you get a User Defined step that contains the template's steps. You can edit those steps locally without affecting the master, and edits to the master propagate back to non-overridden instances.

Settings

The User Defined editor shows:

• Template info — the template name, the number of embedded steps, and a "Modified" badge if any embedded step has been changed locally.
• Helper note: "💡 Use the pencil button to edit this instance. Right-click the template in the toolbox to edit the root."
• Parameters (when the embedded steps reference $placeholders) — one input per parameter, labeled with $name.

When the test's self-healing mode is Per Step, a per-step Self-healing toggle also appears.

The embedded steps themselves aren't edited inside this dialog — use the pencil button on the User Defined step in the test column to open the embedded-steps editor. To edit the master template instead, right-click the template in the toolbox.

What's possible

• Reuse a step sequence across many tests — author once as a template, drop instances anywhere.

• Edit an instance without forking the master — use the pencil button to tweak embedded steps inside one test; other instances are untouched. The edited step is locally overridden so future template edits skip it.

• Per-instance parameter values — set different arguments on each instance to customize behavior without changing the template.

• Add steps inside an instance — steps you add (vs. clone) have no template link and are left alone by template propagation.

What's not possible

• Sharing templates across Macs without Cloud Sync — until Cloud Sync covers them on your install, templates are per-machine.

• Multi-level template composition — a template can't itself contain a User Defined step pointing at another template (template propagation is one level deep, mirroring the one-level conditional-children rule elsewhere).

• Renaming a template and having call sites stay linked — the link is by template identity (not name), so renames are fine; deleting the template orphans every instance.

Common patterns

• login template. Bottle up the Tap-Type-Tap-Type-Tap of your sign-in flow as a template with $email / $password. Drop it as the first step of every authenticated test.

• select-product-by-id template. A small template with $productId that scrolls until the row is found and taps it.

• Tweak an instance for a one-off test. Need this particular sign-in to use a custom timeout? Use the pencil button to edit the embedded Wait Until inside this instance — the master and other instances stay as they were.

Push from template

When you save changes to the master template, every instance picks up the change automatically — except for steps you've locally overridden inside an instance, or steps you added inside an instance (which aren't tied to the template).