In rough order of how often they cause a failure.<\/p>\n
The interface changed.<\/strong> A button moved, a field was renamed, a page was redesigned. The most common by far, and cloud applications are the worst because vendors update without asking.<\/p>\n An unexpected popup.<\/strong> A survey, a cookie notice, a “new features” dialog. The automation was not expecting it and does not know what to do.<\/p>\n Timing.<\/strong> The application was slower than usual and the automation acted before the page was ready.<\/p>\n Credentials.<\/strong> A password policy forced a change, or an account was locked.<\/p>\n Three of the four only apply to screen automation.<\/strong> That is the case for using as little of it as possible.<\/p>\n A selector is how an automation finds an element on screen.<\/strong> It is where most breakage happens.<\/p>\n A fragile selector<\/strong> relies on something that changes \u2014 position on the page, a generated ID that differs each session, or the order of elements.<\/p>\n “The third button in the toolbar” works until somebody adds a fourth button.<\/p>\n A stable selector<\/strong> uses something meaningful and unchanging \u2014 a name, an automation ID, a label, an accessible role.<\/p>\n Two habits:<\/strong><\/p>\n Prefer identifiers over position.<\/strong> Always.<\/p>\n Use the narrowest reliable match.<\/strong> A selector describing the whole page path breaks when any part of that path changes. One that finds the element by its own attributes does not.<\/p>\n FIGURE 1: SELECTORS THAT SURVIVE<\/p>\n Stable<\/p>\n Fragile<\/p>\n Worse than breaking is not breaking properly.<\/strong><\/p>\n A selector that matches the wrong element does not error. It clicks something, and the automation carries on.<\/p>\n Which produces a run that reports success and did the wrong thing.<\/strong><\/p>\n Two defences:<\/strong><\/p>\n Verify after acting.<\/strong> After clicking Submit, check the page changed as expected. After downloading, check the file exists and has content.<\/p>\n Fail on ambiguity.<\/strong> If a selector could match more than one element, that is a problem to surface, not to resolve by picking the first.<\/p>\n The second most common cause.<\/strong><\/p>\n The application was slower today. The automation clicked before the page was ready.<\/p>\n The wrong fix:<\/strong> a fixed pause. Wait five seconds and hope.<\/p>\n Too short<\/strong> and it still fails on a slow day. Too long<\/strong> and every run wastes the difference.<\/p>\n The right fix:<\/strong> wait for the element to be present and ready, with a timeout.<\/p>\n Faster on good days, reliable on bad ones<\/strong>, and when it does time out you get a clear error rather than a mysterious wrong click.<\/p>\n Applications interrupt.<\/strong> A survey, a notification, a consent banner, an update prompt.<\/p>\n Two approaches:<\/strong><\/p>\n Handle known ones explicitly.<\/strong> If a particular dialog appears sometimes, add a step that dismisses it if present.<\/p>\n Handle the unknown ones structurally.<\/strong> Wrap the interaction so that an unexpected blocking element produces a clear error rather than a hang.<\/p>\n And reduce the surface.<\/strong> An automation that does one thing in a browser meets fewer popups than one doing twelve.<\/p>\n FIGURE 2: MAKING IT BREAK LESS OFTEN<\/p>\n Use the least fragile method<\/p>\n Stable selectors<\/p>\n Wait for elements, not clocks<\/p>\n Verify after acting<\/p>\n Keep the screen-automation part as small as the problem allows.<\/strong><\/p>\n If a process needs one step that genuinely requires a browser and eight that do not<\/strong>, do the one and let reliable methods handle the rest.<\/p>\n Then when the site redesigns \u2014 and it will \u2014 one small step needs fixing rather than the whole chain.<\/strong><\/p>\n Concretely:<\/strong><\/p>\n Is there a direct URL?<\/strong> Request it rather than navigating.<\/p>\n Is there an API?<\/strong> Use it.<\/p>\n Can you hand off early?<\/strong> Get the file, then let a workflow tool do everything after.<\/p>\n Every step you remove from the browser is a step that will not break.<\/strong><\/p>\n Three practices:<\/strong><\/p>\n A dedicated service account<\/strong>, not a real person’s login. When they leave or change their password, the automation should not break.<\/p>\n Stored in the platform’s credential store<\/strong>, not in the automation itself.<\/p>\n Expiry tracked.<\/strong> If the account is subject to a password policy, know when it will force a change and plan for it rather than discovering it at 3am.<\/p>\n The proactive part<\/strong>, and what separates well-run RPA from constant firefighting.<\/p>\n Keep a list:<\/strong> which automations depend on which applications.<\/p>\n Subscribe to release notes<\/strong> for those applications. Cloud vendors usually announce interface changes.<\/p>\n Test after a known update<\/strong> rather than waiting for the failure.<\/p>\n Without the dependency list<\/strong>, an announced change means checking everything or nothing.<\/p>\n FIGURE 3: WHEN SOMETHING BREAKS<\/p>\n The alert arrives<\/p>\n Check what changed<\/p>\n Fix the selector or the step<\/p>\n Test the rest<\/p>\n Some fragility is unavoidable.<\/strong><\/p>\n If you are automating against a website you do not control, a redesign will break it. No selector strategy prevents that.<\/p>\n What you can control:<\/strong><\/p>\n How much breaks.<\/strong> Keep the screen part small.<\/p>\n How quickly you know.<\/strong> Alerts, not silence.<\/p>\n How quickly it is fixed.<\/strong> A named owner and clear logging.<\/p>\n Budget for maintenance.<\/strong> RPA is build plus upkeep, indefinitely. Companies that budget for this are satisfied. Companies that do not end up with automations nobody dares touch.<\/p>\n Four causes:<\/strong> interface changes, popups, timing, credentials. Three only apply to screen automation.<\/p>\n Use stable selectors<\/strong>, wait for elements rather than clocks, and verify after acting so a wrong click fails rather than passing silently.<\/p>\n But the biggest lever is design.<\/strong> Keep the screen part small, use HTTP requests and APIs wherever they exist, and hand off early.<\/p>\n You cannot stop a website redesigning. You can decide how much of your process it takes with it.<\/strong><\/p>\n Automations that keep breaking?<\/p>\n Get in touch. Usually the fix is design rather than selectors \u2014 the fragile part is doing more than it needs to.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" The four reasons In rough order of how often they cause a failure. The interface changed. A button moved, a field was renamed, a page was redesigned. The most common by far, and cloud applications are the worst because vendors update without asking. An unexpected popup. A survey, a cookie notice, a “new features” dialog. […]<\/p>\n","protected":false},"author":3,"featured_media":9316,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23],"tags":[],"class_list":["post-9315","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-robotic-process-automation"],"yoast_head":"\nSelectors<\/h2>\n
\n
\n
The silent failure<\/h2>\n
Timing<\/h2>\n
Popups<\/h2>\n
\n
\n
\n
\n
The design decision that matters most<\/h2>\n
Credentials<\/h2>\n
Watching for changes upstream<\/h2>\n
\n
\n
\n
\n
Accepting some breakage<\/h2>\n
The short version<\/h2>\n