Business Browser Automation

Choose a task with an observable result

Write the job in one sentence: download the approved order-status report for the previous business day. Name the portal, account, report and person who uses the file. This defines a testable outcome. A vague instruction to manage the portal leaves too many decisions unresolved.

Check whether the portal offers a scheduled export, supported integration or documented API. These can avoid dependence on page layout. Browser interaction is useful when the work genuinely requires visible controls and the provider permits it. Confirm the account’s rights before building the workflow.

For a first trial, favour reading or downloading information. Changes such as cancelling orders or submitting commitments need their own approval rules. Give the automation only the permissions required for its agreed job.

Describe the page states the workflow must recognise

Record the starting screen, the expected account name and the controls used to select the report. Include the state after each action: the chosen date range, a ready download button and a completed file. A script should be able to distinguish a successful step from a page that is still loading.

When a developer uses Playwright, its locators can identify controls by role or label. Its actionability checks wait for conditions such as a visible, enabled target before clicking. These features help with page timing; the business still needs separate checks that the selected order or reporting period is correct.

Avoid relying only on a button’s screen position. A new banner or resized window can move it. If two matching buttons appear, stop and identify the correct section instead of choosing one arbitrarily. Give unexpected layouts a review path.

Work through a daily portal download

Worked example: a small distributor needs the previous day’s open-order report before its morning meeting. The portal uses the business’s local timezone. On Monday, the owner wants Sunday’s records, including an empty report when no orders exist. Write that rule down; another team might instead want the last working day.

The workflow signs in through the normal route, confirms the distributor account, selects the exact reporting dates and starts the export. It then checks the downloaded file’s type, expected columns and reporting period. A login page saved with a spreadsheet filename must fail validation.

Give the run a stable identifier such as portal account plus report type plus reporting date. If that run already has a verified output, reuse it or mark a deliberate revision. Downloading the same source twice should not create two sets of orders downstream.

Handle sign-in and private files deliberately

Keep passwords and saved sessions out of shared scripts, screenshots and ordinary logs. Playwright’s authentication guidance notes that stored browser state can contain sensitive cookies and headers. Treat a saved session as account access, with restricted storage and a defined expiry.

If the session expires, let the normal sign-in process run. A required CAPTCHA or extra verification needs the authorised user’s participation. Do not turn a login problem into repeated attempts or work around the provider’s restrictions.

Download reports into an agreed private location. Save enough diagnostic evidence to identify the failed step, while excluding unnecessary customer information. Decide who can view those records and how long they are retained.

Decide what a retry is allowed to do

A failed download and an uncertain order submission are different situations. For a download, check for an already completed file before starting again. For a state-changing action, inspect the portal’s result or history first. A timeout can occur after the server has accepted the action.

Define a small retry limit for temporary loading failures. Escalate permission errors, a changed account identity and unexpected confirmation screens. Keep the last verified step so the operator can resume with context.

Test a slow page, an expired session, an empty report, two similarly named accounts and a changed column heading. Compare the downloaded records with a manual run. Measure time spent supervising and fixing exceptions as well as the time saved clicking.

Scope a browser workflow with Automations For Business

Automations For Business can help map a permitted portal task, choose reliable checks and build a review step around uncertain results. Start with the task description, a sanitised example file and the portal’s supported access options.

Use the workflow automation service linked below to discuss the first run. The failure-recovery article explains how to keep an exception queue useful. Expand the workflow only after the pilot completes correctly across the conditions your team actually encounters.

Your ready-to-use checklist

Make the next step clear.

Sources and notes

Sources checked on October 24, 2026.

• Playwright: Locators

  Official guidance on identifying visible controls by roles and labels.

• Playwright: Auto-waiting

  Actionability checks for browser operations.

• Playwright: Authentication

  Handling stored authentication state carefully.