Give parallel browser jobs an account-level budget

A team splits a monthly reporting task across four browser sessions. Each session navigates independently. All four use the same account, request exports at once, and reach the same account-level limit.

The navigation is isolated. The workload still needs coordination.

This is a design walkthrough for that problem, not a measurement of a particular portal or a claim about BrowserAct throughput. BrowserAct supports parallel sessions that share a browser's login state while keeping their active navigation separate. That capability answers where a task runs. Your application still needs to decide when a shared account should receive more work.

Identify the resource being shared

Start by separating three identifiers in the job record:

• The job identifies the requested outcome, such as one account's September report.
• The browser identifies the configured browser environment and login context.
• The session identifies the live execution context created for this attempt.

A session name is useful for routing commands. It does not establish that two jobs are independent at the business level. Two different sessions can still request the same document or change the same setting.

Record the business account separately as well. Several configured browsers might access the same portal account, so a browser ID alone may be an incomplete key for scheduling account-wide work.

Classify operations before adding workers

Reading independent report pages is different from updating account settings or starting an expensive export.

For an initial implementation, classify the steps by their effect. Independent reads may be candidates for bounded parallel execution. Account-wide changes deserve explicit sequencing. Export generation may need its own limit even when reading pages works concurrently.

Those are starting assumptions to validate for the actual portal. A site may enforce a total session limit, or a seemingly harmless action may update shared preferences. Separate browser windows do not tell you how the server handles concurrent requests.

You can begin with a small operation map:

report-page read: allow a small number in parallel
export generation: serialize until behavior is understood
account preference update: serialize
file verification after download: run locally and independently

This is an application design example, not a BrowserAct configuration file or a tested policy for any named vendor.

Put admission control outside the browser

Give the coordinator a queue keyed by the actual shared resource, such as portal plus account plus operation class. Only create or assign an execution session after the coordinator admits the job.

This avoids a common waste pattern: opening many sessions and then letting all of them wait on the same account restriction. Waiting jobs can remain ordinary queue records without occupying a live browser execution context.

A minimal job lifecycle might be:

waiting -> admitted -> executing -> verifying -> completed
                         |
                         +-> waiting_for_dependency
                         +-> needs_review

The coordinator owns these states. They are not statuses returned by BrowserAct. Keep its scheduling decision separate from what the browser observed so a failed page load cannot accidentally become a successful business result.

Release capacity deliberately

Capacity should return to the coordinator when the attempt ends, including failures. Session cleanup and business completion are related but different responsibilities.

A job can close its session after saving evidence and still remain incomplete because the export contains the wrong dates. Conversely, a completed file should not need its browser session kept open indefinitely.

When a human action is required, record that dependency explicitly. Avoid occupying every worker slot with attempts waiting on the same unresolved account login. The appropriate resume path depends on the workflow and the existing authenticated environment; do not assume a new session removes the dependency.

Retry the missing outcome

Give each requested output a stable business key. For example, combine the account, document type, date range, and document identifier when that identifier exists.

Before retrying, check for an already verified artifact with that key. A browser timeout after an export click leaves an uncertain outcome, not proof that the export failed. Inspect the existing job or saved result before starting the same export again.

If the portal reports a limit, record the observed message and any stated retry time. Keep that account's dependent jobs waiting while unrelated accounts continue within their own budgets. Do not increase concurrency in response to a rate-limit error.

Measure useful parallelism

Track verified outputs alongside active sessions, waiting time, repeated requests, and required human intervention. More open sessions are only useful if they improve completion without producing duplicate work or increasing account-level failures.

Start with a conservative limit, observe the actual workflow, and change one constraint at a time. There is no universal worker count that follows from the browser's ability to open another session.

Our concurrent browser automation guide covers the session and identity model behind this design. The account-level coordinator described here belongs to the application that schedules the work.