Attended<\/strong> runs on a person’s machine, usually started by them. They are there while it works.<\/p>\n Unattended<\/strong> runs on a server, on a schedule, with nobody watching.<\/p>\n It sounds like a deployment detail.<\/strong> It is not \u2014 it changes what the automation has to handle.<\/p>\n A person is present.<\/strong><\/p>\n If something unexpected happens, they see it. If a popup appears, they close it. If the result looks wrong, they notice before it matters.<\/p>\n Which means the automation can be less defensive.<\/strong> Not that error handling is optional \u2014 but the consequences of missing a case are smaller, because somebody is watching.<\/p>\n Good for:<\/strong><\/p>\n Work a person triggers.<\/strong> They received a batch and want it processed now.<\/p>\n Tasks alongside a person.<\/strong> Filling a form from data they have open.<\/p>\n Anything still being proven.<\/strong> Run it attended while you find out where it breaks.<\/p>\n Anything needing a decision partway.<\/strong> A person can answer a question the automation cannot.<\/p>\n Nobody is there.<\/strong><\/p>\n Four things become essential rather than nice to have:<\/strong><\/p>\n Error handling that works alone.<\/strong> No person to close a dialog or retry manually.<\/p>\n Logging detailed enough to explain a failure the next morning.<\/strong> The log is all anyone will have.<\/p>\n Errors that surface.<\/strong> A job that swallowed an error and exited successfully is worse than one that failed \u2014 it records a false success and nobody is alerted.<\/p>\n Alerts that reach a person.<\/strong> Including when the job did not run at all, which produces no error.<\/p>\n FIGURE 1: WHAT EACH ONE DEMANDS<\/p>\n Attended<\/p>\n Unattended<\/p>\n The job that did not run.<\/strong><\/p>\n An attended automation not running is obvious \u2014 the person clicked and nothing happened.<\/p>\n An unattended one produces nothing at all.<\/strong> No error, no log entry, no alert. Silence.<\/p>\n And silence looks exactly like success<\/strong> to anyone not checking.<\/p>\n Two things to set up:<\/strong><\/p>\n Monitor for the absence.<\/strong> Alert if a scheduled job has not reported by an expected time.<\/p>\n Log successful runs too<\/strong>, not just failures. A gap in the success log is visible; nothing at all is not.<\/p>\n Attended<\/strong> runs on a person’s desktop. It shares the machine with them, which means it can be affected by what else they are doing \u2014 and it only runs when their machine is on.<\/p>\n Unattended<\/strong> runs on a dedicated machine or server. It needs:<\/p>\n To stay available.<\/strong> Powered on, connected, logged in as required.<\/p>\n Credentials that survive.<\/strong> A dedicated service account, not a person’s login that expires or gets locked.<\/p>\n A defined schedule<\/strong>, and a rule for what happens if a run overlaps the previous one.<\/p>\n That last one catches people.<\/strong> A job scheduled hourly that sometimes takes ninety minutes will eventually run twice at once. Decide whether that is safe.<\/p>\n FIGURE 2: WHAT UNATTENDED NEEDS THAT ATTENDED DOES NOT<\/p>\n Monitoring for silence<\/p>\n A dedicated service account<\/p>\n An overlap rule<\/p>\n Logging that explains<\/p>\n The right progression<\/strong>, and worth doing deliberately.<\/p>\n 1. Build it attended.<\/strong> A person triggers it and watches.<\/p>\n 2. Run it that way for a few weeks.<\/strong> You will find cases you did not anticipate \u2014 that is the point.<\/p>\n 3. Strengthen the error handling<\/strong> based on what you found.<\/p>\n 4. Add logging and alerting.<\/strong><\/p>\n 5. Move to unattended<\/strong>, and watch the first runs closely.<\/p>\n 6. Add monitoring for silence.<\/strong><\/p>\n Skipping to unattended<\/strong> means discovering the exceptions with nobody watching, which is how weeks of missing data happen.<\/p>\n Attended when:<\/strong><\/p>\n The person is there anyway, triggering it as part of their work.<\/p>\n The volume is low.<\/p>\n A decision may be needed partway.<\/p>\n You are still proving the process.<\/p>\n Unattended when:<\/strong><\/p>\n It runs on a schedule, often outside working hours.<\/p>\n Nobody needs to be involved.<\/p>\n It runs often enough that manual triggering is a burden.<\/p>\n The process is stable and proven.<\/p>\n FIGURE 3: THE PROGRESSION<\/p>\n Build attended<\/p>\n Run for weeks<\/p>\n Strengthen and instrument<\/p>\n Then unattended<\/p>\n Unattended robots are typically licensed differently from attended ones<\/strong>, and usually cost more.<\/p>\n Which is a real consideration<\/strong> when deciding how many automations to run unattended.<\/p>\n Pricing changes<\/strong>, so get current figures from the vendor rather than any article.<\/p>\n A practical note:<\/strong> several automations can often share an unattended robot if their schedules do not overlap. Worth planning schedules with that in mind.<\/p>\n Attended means a person is there.<\/strong> Lower risk, less defensive coding needed, and the right place to start.<\/p>\n Unattended means nobody is.<\/strong> Every case must be handled, logging must explain a failure the next morning, and alerts must reach somebody.<\/p>\n Monitor for silence, not just errors.<\/strong> A scheduled job that did not run produces nothing at all \u2014 and nothing looks exactly like success.<\/p>\n Build attended, prove it, then move.<\/p>\n Automation running overnight with nobody watching?<\/p>\n Get in touch. We set up the alerting that catches the failure nobody sees \u2014 including the job that simply did not start.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" The difference Attended runs on a person’s machine, usually started by them. They are there while it works. Unattended runs on a server, on a schedule, with nobody watching. It sounds like a deployment detail. It is not \u2014 it changes what the automation has to handle. Why attended is easier A person is present. […]<\/p>\n","protected":false},"author":3,"featured_media":9313,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23],"tags":[],"class_list":["post-9312","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-robotic-process-automation"],"yoast_head":"\nWhy attended is easier<\/h2>\n
Why unattended demands more<\/h2>\n
\n
\n
The failure that only affects unattended<\/h2>\n
Machine and environment<\/h2>\n
\n
\n
\n
\n
Moving from attended to unattended<\/h2>\n
Choosing for a given task<\/h2>\n
\n
\n
\n
\n
Licensing<\/h2>\n
The short version<\/h2>\n