Workspace & Team

Invite your team, organize workspaces, track usage and billing, and keep an audit trail. Everything about running RamAIn together.

Everything you build in RamAIn lives in a shared workspace. Workflows, agents, sessions, Passwords, and the team inbox belong to the team, so anyone with the right role can pick up where a colleague left off. This page is the admin handbook: people and roles, workspace structure, usage, billing, and audit.

Team & roles

Invite colleagues from the Team page: enter an email address, pick a role, and send. The invitee gets an email link and lands in your workspace as soon as they accept. The member list shows everyone in the workspace with their role, and admins can change a member's role or remove them from the same page.

The Team page: the member list with each person's role

RoleCan do
AdminEverything: full org access, billing, and team management.
BuilderCreate, edit, and launch workflows and agents.
MemberUse what's shared: launch workflows and view runs and sessions.

What each role sees day to day:

  • Admins get the full sidebar, including Billing, Usage, the Audit log, API keys, and team management. On the Team page they can invite, change roles, and create new workspaces.
  • Builders live in the workbench: they see Workflows, Agents, Triggers, Sessions, Passwords, and the inbox, and can publish and launch anything they build.
  • Members see the shared library. They can launch published workflows, follow runs, and browse session history, but they don't edit graphs or manage the workspace.

To change someone's role, open the Team page, find them in the member list, and pick the new role. The change applies immediately; there is no re-invite.

Because the workspace is shared, a workflow one builder publishes is instantly launchable by the whole team, its sessions show up in everyone's history, and its triggers keep running no matter who created them.

Organizations and sub-organizations

Larger teams often want separation: one space per department, per client, or per region. A parent organization can create additional workspaces (sub-organizations) directly from the Team page with New workspace.

Creating a sub-organization from the Team page

Each sub-organization is a full workspace of its own:

  • its own members, invited and role-managed independently,
  • its own workflows, agents, sessions, and Passwords,
  • its own team inbox with a dedicated address.

Billing stays simple: credits and charges from every sub-organization roll up to the parent, so there is one balance to fund and one place to watch spend.

The Org Chart view on the Team page visualizes the whole structure, from the parent organization down through each workspace and its members.

The Org Chart view: the parent organization and its workspaces at a glance

Parent-organization admins keep visibility across every sub-organization. They can see the audit trail and usage for each workspace (both are scoped per workspace, so numbers never blur together), which makes the parent org the natural home for compliance and finance.

Your account

The Account page holds your personal profile: name, email, and sign-in settings. It's per-person, unlike everything else on this page, which is shared with the workspace.

The Account page: your personal profile and sign-in settings

Team inbox & phone

Your workspace has its own email address and phone number that workflows can read from and reply through. See Team inbox.

Passwords

Credentials the agents use are stored once as workspace Passwords: encrypted, shared with the team, and never echoed in chat or exposed through the API.

Data integrations

Org admins can connect organization data sources such as Microsoft OneDrive; builders then import files into any workflow's datastore straight from the editor. See Data integrations.

Usage analytics

The Usage page answers "where do our credits go?" It opens with the headline numbers and drills down from there.

The Usage page: balance, burn rate, daily spend, and consumption by feature

The key metrics:

  • Prepaid credits: your current balance, what's left to spend.
  • Charged: how much has been consumed in the selected period.
  • Granted / top-ups: credits added in the period, whether purchased or granted by RamAIn.
  • Burn rate and estimated days remaining: your recent daily average and, at that pace, how long the current balance lasts. Treat it as an early warning, not an invoice.

Below the headline numbers, the daily spend chart shows consumption day by day, so a spike (a heavy backfill, a runaway schedule) is visible immediately. Consumption by feature splits spend across what actually uses credits: sessions, workflow runs, and SOP generation. Per-member usage shows the same split by teammate, which helps when one team's experiments dominate the bill.

Two controls scope everything on the page:

  • Time period: 7, 30, or 90 days.
  • Workspace scope: All aggregates across the parent organization and every sub-organization; selecting a single workspace shows just that workspace's numbers.

Billing

RamAIn runs on prepaid credits, which power sessions, workflow runs, and SOP generation. The Billing page is where admins manage the money side.

The Billing page: prepaid balance, top-ups, and recent charges

  • Prepaid balance shows what the organization has left, in one place even when several sub-organizations draw from it.
  • Add credits tops the balance up. Credits never expire into thin air; they sit on the balance until runs consume them.
  • The consumption breakdown by workspace shows which sub-organization is spending what, matching the scoped view on the Usage page.
  • Recent charges lists per-run costs; click into any charge to see which workflow ran, when, and what it consumed.
  • A billing contact can be set so invoices and balance notifications go to the right inbox, even if that person rarely logs in.

Per-workflow credit estimates also appear in the in-portal API docs, so builders can see what a launch costs before wiring it into a system. For plans and rates, see Pricing.

Audit log

Workspace admins get an immutable audit log under Resources → Audit. It records the events that matter for compliance and for answering "who changed this?":

  • Team: invites, role changes, removals.
  • Workflow: creations, edits, publishes, deletions.
  • Run: launches and terminal outcomes.
  • Trigger: schedules and email triggers created, changed, or disabled.
  • API key: keys created, used for the first time, or revoked.
  • Organization: new workspaces and structural changes.

The Audit page: day-grouped events with category chips and actors

Events are grouped by day, and each entry shows a category chip, the actor, and their role at the time. Filters and search narrow the stream to one category, one person, or one workflow. Where an event points at something inspectable (a run, a workflow version), a Review link deep-links straight into the workbench so you can see exactly what the entry refers to.

Two properties worth knowing: the log is immutable (entries can't be edited or deleted, by anyone), and it's scoped to parent-organization admins, who see the trail across every sub-organization.

Special agents

Some organizations have bespoke agents, for example document anonymisation, built and enabled by the RamAIn team for their specific needs. When granted, they appear in your sidebar like any other tool and follow the same roles and audit rules as the rest of the workspace.

Was this page helpful?