Sola onboarding checklist: what access do bots need for browser portals and Windows desktop apps?

Most teams are surprised by how little “special” access Sola bots actually need. Because Sola automates work at the UI level—visually interacting with browser portals and Windows desktop apps the same way your team does—the onboarding checklist is mostly about giving bots the right user accounts, permissions, and environment to operate safely.

Quick Answer: Sola bots need the same application access a human operator would use for that workflow—no privileged backdoor, no deep system install. For browser portals and Windows desktop apps, plan on scoped user accounts, SSO or credential vault access, stable workstations/VMs to run bots, and appropriate role-based controls and monitoring so operations leaders stay in control.

Why This Matters

Getting access right during onboarding is what determines whether your first Sola automations go live in days or stall for weeks in security reviews. Sola is designed to run in regulated, UI-driven environments—claims, filings, invoice reconciliation, order entry—so you can give bots enough access to be useful, but stay firmly within your existing security, compliance, and audit expectations.

Key Benefits:

• Faster go-live: A clear checklist lets IT, security, and operations agree on bot access up front, reducing back-and-forth and delays.
• Stronger governance: Scoped permissions, SSO, and audit trails keep you in control of who (or what) can touch sensitive systems.
• Less maintenance overhead: Standardized access patterns—per-bot or per-team accounts, consistent workstation setup—make it easier to scale and maintain automations over time.

Core Concepts & Key Points

Concept	Definition	Why it's important
UI-level automation	Sola bots visually interact with browser and desktop apps, replicating a human’s clicks, typing, and navigation.	You don’t need new APIs or deep code changes—just the same app access and screens your team uses today.
Scoped bot identities	Dedicated user accounts (often tied to SSO) that represent each bot or automation team.	Limits blast radius, simplifies audits, and aligns with least-privilege principles in regulated environments.
Run environment	The machines (physical or virtual) where Sola bots execute workflows across browser and Windows apps.	Consistent, controlled environments reduce brittleness and make it easier to monitor and govern automations.

How It Works (Step-by-Step)

Sola’s agentic process automation starts from a real workflow—say, invoice reconciliation that touches an ERP web portal, a vendor portal in Chrome, and a Windows desktop accounting app. You record the process once, and Sola turns it into a bot that can run across those browser portals and desktop applications, adapting when minor UI or data formats change.

1. Define the workflows and target systems

Before you think about access, get specific about what the bot will actually do:

• Which browser portals? (e.g., SAP web, Netsuite, carrier portals, legal e-filing sites)
• Which Windows desktop apps? (e.g., legacy ERP, billing tools, claims systems, document management clients)
• What data will it read, write, or update? (invoices, claims, customer records, filings, shipments, etc.)
• Which human role does this mirror today? (billing analyst, claims adjuster, legal operations specialist)

This step makes it easy to align bot permissions to a real job function instead of over-provisioning.

2. Set up bot identities and access

Next, you give Sola bots the same application-level access a human in that role would have.

For browser portals, Sola bots typically need:

• User accounts or SSO access

  • SSO (Okta, Azure AD, etc.) or username/password accounts with appropriate role-based permissions.
  • Ideally, dedicated bot accounts (e.g., billing-bot@company.com) rather than sharing human logins.

• Role-based permissions

  • Match the human operator’s role: view/update the specific entities the workflow needs.
  • Avoid unnecessary admin rights—stick to least privilege.

• 2FA / MFA strategy

  • If MFA is required, decide whether to:
    • Use service accounts exempted from interactive MFA but strongly controlled and monitored, or
    • Use an MFA method that’s compatible with automated operation (hardware or virtual tokens managed by IT).

For Windows desktop apps, Sola bots typically need:

• Windows user accounts

  • Domain or local accounts with permissions to:
    • Log in to the machine or VM where the bot runs.
    • Launch and use the desktop applications in scope.
  • Again, prefer dedicated bot or service accounts over shared operator accounts.

• Application-level access

  • Any licensing, app roles, or group memberships a human user would need to open, read, and update records.
  • File system access if the workflow reads/writes local files or shared network drives.

• Network access

  • Ability to reach any required internal endpoints, shares, or on-prem systems used by the desktop app.

In both cases, Sola doesn’t require system-level privileges beyond what’s necessary to log in and run your apps the way a human would.

3. Prepare the run environment and governance

Finally, you set up the environment where bots will run and how you’ll monitor them.

For browser portals:

• Standardized browser setup

  • A modern browser (Chrome/Edge) with any required extensions, security policies, and cookies/session settings.
  • If you use strict security controls (e.g., content blockers, corporate proxy), ensure bot machines inherit appropriate policies.

• Stable display and OS settings

  • Consistent resolution and scaling so UI elements appear in predictable locations for computer-vision-based interaction.
  • Up-to-date OS and browser versions, updated in a controlled, observable way.

For Windows desktop apps:

• Consistent VM or workstation images

  • Core apps installed and configured (including any prerequisites like .NET, Java, database drivers).
  • Standard user profiles so paths, shortcuts, and registry keys are predictable.

• Session management

  • Clear policies for how and when bots log in, log out, and reclaim sessions.
  • If you use VDI or RDP, ensure bots can open the remote session and control the UI reliably.

For governance across both:

• Monitoring & logs

  • Use Sola’s real-time logs and audit trails to see what each bot ran, when, and with which inputs—so you’re never in the dark.
  • Align bot activity with your SIEM or monitoring tools where appropriate.

• Role-based access controls

  • Limit who can create, edit, and trigger bots in Sola.
  • Ensure changes to workflows follow your usual change-management procedures in operations.

• Compliance alignment

  • Sola supports enterprise expectations (SOC 2, HIPAA, role-based access controls), but you should still classify automations by data sensitivity and apply additional controls (e.g., stricter monitoring for PHI or financial data).

Common Mistakes to Avoid

• Over-privileging bot accounts:

  • Giving bots broad admin access “just to be safe” increases risk and makes security uncomfortable.
  • How to avoid it: Map bot roles to real jobs (claims analyst, billing specialist) and mirror those permissions only.

• Treating bot machines as one-off snowflakes:

  • Custom, hand-configured machines make automations brittle and hard to scale.
  • How to avoid it: Standardize VM images and browser/desktop setups so adding a new bot is repeatable and predictable.

Real-World Example

A logistics operations team uses Sola to automate thousands of shipment updates every week. The workflow touches:

• A carrier portal in Chrome to pull tracking data
• An internal TMS web app to update shipment statuses
• A Windows desktop billing tool to adjust invoices

During onboarding, IT:

1. Creates dedicated SSO-backed accounts for ops-bot with the same roles as a human operations analyst—no admin rights.
2. Provisions a Windows VM image with Chrome, the TMS desktop shortcuts, and the billing app installed, plus access to required network shares.
3. Whitelists the VM group for the carrier and TMS portals while enforcing standard security policies and logging.

The ops analyst records the exact workflow once in Sola. Now, the agentic bot runs across browser portals and the Windows app, adapting to minor UI changes and surfacing detailed logs. Operations leaders have centralized oversight, security has clearly scoped access, and no one needed to write code or bring in RPA consultants.

Pro Tip: When planning your first few Sola bots, document “if a human had to do this job, what systems would they need, and what could they see or change?” Use that as the template for bot permissions—it keeps you aligned with least privilege and makes security reviews much faster.

Summary

Onboarding Sola bots for browser portals and Windows desktop apps is less about exotic system access and more about disciplined, human-like permissions: scoped user accounts, SSO where possible, a consistent run environment, and clear governance. Because Sola automates at the UI level—visually interacting with screens and apps like your team does—you can reuse your existing roles and security models while adding real-time visibility and audit trails on top. That’s how you automate invoice reconciliation, order entry, claims processing, and complex filings at scale, without ripping out legacy systems or overhauling your security posture.

Next Step

Get Started