How do I set up RBAC and approvals in Sola so only certain teams can create/edit/run automations?

For most teams rolling out Sola, the hard part isn’t building automations—it’s making sure only the right people can create, edit, and run them. That’s where role-based access control (RBAC) and lightweight approvals come in: they let you move fast on automation while staying compliant, auditable, and sane.

Quick Answer: Use Sola’s role-based access controls to define who can view, create, edit, approve, and run automations by workspace and role (e.g., ops, compliance, IT). Then layer on approval flows so changes to high-risk workflows (like payments or claims) require sign-off before going live. The result is simple: business teams can build, while governance teams control what ships to production.

Why This Matters

If you’re automating workflows like invoice reconciliation, claims processing, or order entry, the risk isn’t that someone builds a bot—it’s that the wrong bot runs in production, or the right bot runs with the wrong permissions.

Without clear RBAC and approvals in Sola, you can end up with:

• Automations that touch sensitive systems without oversight
• “Shadow RPA” where anyone can ship a bot that changes production data
• No audit trail when a workflow fails and you need to know who changed what

With the right setup, you get a clean separation of duties: analysts and ops teams can record and iterate; leads and admins review and approve; and IT/security keeps the overall guardrails in place—without becoming the bottleneck.

Key Benefits:

• Controlled creation and editing: Let subject-matter experts build automations while limiting who can publish or modify production bots.
• Safe execution of high-impact workflows: Ensure only authorized teams can run automations that touch financials, PHI, or core systems.
• Compliance-ready oversight: Maintain audit trails, approvals, and role-based access so you can prove control to auditors, regulators, and internal security.

Core Concepts & Key Points

Concept	Definition	Why it's important
RBAC in Sola	A role-based system that controls who can view, create, edit, approve, and run automations, scoped by workspace, team, and data sensitivity.	Prevents over-permissioning while still empowering business users to build; aligns with SOC 2 / HIPAA expectations.
Workspaces & Teams	Logical groupings of automations, data, and users—e.g., “Billing,” “Claims,” “Legal Ops”—with tailored permissions and governance.	Lets you isolate critical workflows (like payments or PHI) and apply stricter controls and approvals where needed.
Approval Flows	Structured review steps (often by a lead or admin) before a new or changed automation can run in production.	Creates separation of duties, reduces risk of breaking changes, and provides an auditable paper trail for changes.

How It Works (Step-by-Step)

At a high level, setting up RBAC and approvals in Sola so only certain teams can create/edit/run automations looks like this:

1. Define roles and access patterns.
2. Configure workspaces, teams, and permissions in Sola.
3. Implement approval flows for sensitive or high-impact automations.

1. Define roles and access patterns

Before you touch settings, get crisp on who should be able to do what. In practice, most Sola customers end up with a structure roughly like:

• Builders (Ops analysts, billing specialists, legal ops, etc.)

  • Can: record workflows, create/edit drafts, run test executions.
  • Can’t: publish directly to production for high-risk workflows without approval.

• Approvers (team leads, managers, process owners)

  • Can: review and approve changes, promote automations to production, manage workspace-level settings for their domain.
  • Can’t: change global security or organization-wide settings.

• Admins (IT, security, platform operations)

  • Can: set up RBAC policies, manage workspaces, enforce global standards, configure integrations and authentication.
  • Typically don’t: own workflow logic—this stays with the business experts.

Write these down per domain (e.g., “Finance,” “Claims,” “KYC”) so you can mirror them 1:1 in Sola.

2. Configure workspaces, teams, and permissions in Sola

Next, you map your org structure into Sola’s RBAC model so only the right people can create, edit, and run automations.

A typical setup:

1. Create workspaces aligned to business domains
   Examples:

   • Finance – Billing & AR
   • Logistics – Order Entry
   • Legal Ops – Claims & Filings
   • Compliance – KYC & Onboarding

   Each workspace becomes a boundary for:

   • Which automations live there
   • Which users can see or touch them
   • Which approval rules apply

2. Assign roles at the workspace level
   For each workspace, assign users or groups to roles such as:

   • Viewer: Can view automations, logs, and status, but cannot create/edit/run.
   • Builder: Can record, create, and edit automations in draft/sandbox; can run test executions.
   • Operator: Can run approved automations, schedule runs, and respond to exceptions—but cannot change workflow logic.
   • Approver: Can approve changes and promote automations to production.
   • Admin: Can manage workspace-level settings, connections, and user assignments (often limited to platform or security teams).

   Mechanically in Sola, you’ll:

   • Add users or SSO groups to the relevant workspace.
   • Assign each user/group to the appropriate role.
   • Confirm that permissions align with your written access patterns.

3. Separate sandbox and production contexts

   For regulated or sensitive workflows, treat your environments as distinct:

   • Sandbox / Dev workspace
     • Builders can freely create and iterate.
     • Lower restrictions; focus on speed.
   • Production workspace
     • Only Approvers/Admins can move automations here.
     • Operators can run and monitor, but not change logic.
     • Often the place where stricter logging/auditing is enforced.

   In Sola, that typically looks like:

   • Finance – Billing (Sandbox)
   • Finance – Billing (Production)

   Then:

   • Builders: Full edit rights in Sandbox, read-only in Production.
   • Approvers: Control promotion from Sandbox to Production.
   • Operators: Run and monitor in Production only.

3. Implement approvals for sensitive automations

Once your roles and workspaces are in place, you layer approvals over any automation that can cause real-world impact if misconfigured.

1. Define what requires approval
   Common categories:

   • Workflows that create or modify records in core systems (ERP, CRM, claims platform).
   • Automations that move money or adjust balances.
   • Processes that touch PHI, PII, or other sensitive data.
   • Cross-system workflows that have side effects in more than one platform.

   You can treat others (like internal reporting or file renaming) as lower-risk and allow direct publishing.

2. Set up approval steps in your Sola process

   In practice, the flow looks like:

   1. Builder records a process in Sola (e.g., invoice reconciliation), turning it into an agentic bot that runs across browser and desktop applications.
   2. Builder tests the workflow in a sandbox environment, using Sola’s visual workflow editor and real-time logs to validate each step.
   3. When ready, the Builder marks the workflow as “Ready for Review” (or equivalent state).
   4. Approver (team lead or process owner) gets notified, opens the workflow:
      • Reviews the steps on the visual canvas.
      • Checks which systems and data types the automation touches.
      • Confirms error-handling paths and any data transformation steps.
   5. Approver either:
      • Sends back with comments (adjustments required), or
      • Approves and promotes the automation into the Production workspace or production state.
   6. Once approved:
      • Operators can run/schedule the automation.
      • Changes to the workflow logic once again require Approver review.

3. Make approvals visible and auditable

   For each automation, you want a clear record of:

   • Who built it
   • Who approved it
   • When it was last modified and by whom
   • What version is currently running in production

   Sola is designed with enterprise governance in mind—real-time visibility, audit trails, and centralized oversight—so you can:

   • See execution logs in real time (so you’re never in the dark when something fails).
   • Track the history of changes and approvals per workflow.
   • Align with SOC 2, HIPAA, and internal audit expectations.

Common Mistakes to Avoid

• Over-permissioning everyone as “Admin”:
  This is the fastest path to losing control. Reserve Admin for platform owners. Give ops teams Builder/Operator and use Approver roles for leads.

• Mixing sensitive and non-sensitive workflows in the same workspace:
  If a workspace contains both “rename files” and “move money,” you’ll over-regulate everything. Use separate workspaces (or environments) so you can apply appropriate RBAC and approval rigor only where needed.

• Skipping approvals for “small” changes:
  A minor tweak (like a selector or field mapping) in a claims or billing workflow can cascade into real errors. Treat any change that touches production systems as approval-worthy, and lean on Sola’s logs and audit trails to track the lifecycle.

Real-World Example

Imagine a logistics company using Sola to automate order entry across a web portal, internal TMS, and an ERP. Before Sola, a team member would sit with 15 tabs open, re-keying data all day.

They set up Sola like this:

• Workspaces

  • Logistics – Order Entry (Sandbox)
  • Logistics – Order Entry (Production)

• Roles

  • Ops analysts as Builders in Sandbox; Viewers in Production.
  • The logistics manager as Approver for both workspaces.
  • The platform team as Admins, managing connections and RBAC.
  • Dispatch team as Operators in Production—they run and monitor automations, but can’t change logic.

Workflow:

1. An ops analyst records the manual order-entry process once in Sola. The platform uses LLMs and computer vision to turn that recording into a bot that interacts with the browser-based portal and desktop TMS like a human.
2. The analyst iterates in the Sandbox workspace, using Sola’s visual editor to refine steps and define data transformation logic when inputs are messy.
3. Once satisfied, they mark the workflow “Ready for Review.”
4. The logistics manager reviews the steps, confirms that it handles edge cases gracefully (using Sola’s adaptive, self-healing behavior to stay robust against minor UI changes), and approves promotion to the Production workspace.
5. Dispatch Operators now trigger and monitor the automation from the Production workspace, with real-time logs and audit trails available if anything goes wrong.

Result:
The team gets AI-native automation that works the way they do, without giving every analyst admin-level powers—and without IT spending weeks hardening each bot, as they had to with legacy RPA tools.

Pro Tip: When you onboard a new team to Sola, start with a “low-risk, high-volume” workspace (like internal reporting or file verification) to practice your RBAC and approval patterns. Once you’re confident the controls behave the way you expect, mirror the pattern into higher-stakes domains like billing, claims, or KYC.

Summary

To set up RBAC and approvals in Sola so only certain teams can create, edit, and run automations, you:

1. Define clear roles for Builders, Approvers, Operators, and Admins.
2. Map those roles into Sola using workspaces aligned to business domains and sensitivity.
3. Enforce separation between sandbox and production.
4. Add approvals for any workflow that touches critical systems or sensitive data.
5. Rely on Sola’s real-time logs and audit trails to keep changes and executions transparent.

This gives you the upside of AI-native, agentic process automation—record once, run across your browser and desktop apps—without sacrificing governance, compliance, or operational control.

Next Step

Get Started