Workspace administration
Everything that decides who’s in your Sonora workspace and what they can do lives under Settings. This page covers the admin surface: adding people, the role and permission model that governs access, and the organization-level configuration that shapes how Sonora behaves for everyone. Most of it is gated — a teammate without admin access sees a read-only view, not the controls.
Adding and managing users
Section titled “Adding and managing users”Open Settings → Users to see everyone in the workspace, their assigned role, when they last signed in, and when they joined.
To add someone, click Add user and enter their email address (a display name is optional). Sonora doesn’t send a password — people sign in with the email address you specify, so the address has to match how they authenticate. Once added, a user picks up the default role and can sign in immediately.
You change a person’s role inline from the Role column in the users table, and you remove someone with the delete action on their row. You can’t delete your own account, which avoids locking yourself out of the workspace you administer.
Automatic provisioning
Section titled “Automatic provisioning”If you’d rather not add people one at a time, turn on Auto-provision users at the bottom of the Users page. When it’s enabled, anyone signing in with an email on your organization’s verified domains gets access automatically on first login — no manual invite. The page shows exactly which domains qualify (for example @yourcompany.com).
Auto-provisioned users land in the default role you choose alongside the toggle. If you don’t set one, or you delete the role you’d configured, new users fall back to the Member role. Auto-provisioning is the right call when your whole team should have access by default; leave it off when you want to admit people deliberately.
Managing users — adding, removing, changing roles, and configuring provisioning — requires the users:manage permission, which the Admin role carries. People with read-only access can view the list but won’t see the controls.
Roles and permissions
Section titled “Roles and permissions”Access in Sonora is role-based. Every user holds one role, and each role is a named bundle of permissions. A permission is a single capability — viewing customers, writing notes, managing integrations — expressed as resource:action. When a user tries to do something, Sonora checks whether their role grants the matching permission.
This is the answer to “who can see what.” Roles decide it, and you manage roles from Settings → Roles.
Built-in roles
Section titled “Built-in roles”Three roles ship with every workspace and cover most teams without customization. Each one builds on the one below it: a Contributor can do everything a Member can, plus more, and an Admin can do everything a Contributor can, plus more.
| Role | Who it’s for | What it adds |
|---|---|---|
| Member | Day-to-day users | View customers, people, meetings, issues, and feature requests; use chat and share threads; read and write their own notes; use saved prompts; export data; edit their own profile |
| Contributor | Power users who shape the workspace | Everything in Member, plus authoring and managing saved prompts, managing actions, configuring enrichment columns, and viewing integration status |
| Admin | Workspace administrators | Everything in Contributor, plus inviting and managing users, connecting and configuring integrations, archiving customers, managing organization settings, managing note templates, and sending action emails on another user’s behalf |
Every user can read and update their own profile and use core navigation regardless of role — those are baseline capabilities no role removes.
What each permission controls
Section titled “What each permission controls”Roles are assembled from individual permissions. The ones you’ll assign most often:
| Permission | Grants |
|---|---|
| View customers, people, meetings | Read access to the core records |
| Edit customer data | Change fields such as opportunity details |
| Archive customers | Archive, unarchive, and view archived customers |
| Use chat | Run chat and stream responses; share thread links |
| Read and write notes | View shared notes; create and edit your own |
| Manage saved prompts | Create and edit reusable chat prompts for the team |
| Manage actions | Reassign and edit actions regardless of who they’re assigned to |
| Manage enrichment | Create and edit enrichment columns and run prompts |
| Export data | Download data files |
| View integrations | See integration status and configuration |
| Manage integrations | Connect, configure, and disconnect data sources |
| Manage users | Invite, remove, and reassign roles |
| Manage roles | Create, edit, and delete roles |
| Manage settings | Change organization configuration |
| Manage note templates | Create and edit org-wide note templates |
Permissions follow a containment rule worth knowing: a :manage permission on a resource implies the narrower read and write capabilities for that resource. Granting “manage integrations,” for instance, also grants “view integrations.” You don’t have to check every box individually.
Custom roles
Section titled “Custom roles”When the built-in roles don’t fit — say you want a role that can manage integrations but can’t touch users — create your own from Settings → Roles → New role. Give it a name and description, then check the permissions it should carry. Sonora automatically includes the baseline app-access permission so the role is actually usable.
The permission matrix on the Roles page shows every role next to every permission, so you can see at a glance what each role can do and where custom roles differ from the built-ins. To start from an existing role rather than a blank slate, duplicate it and adjust.
A few guardrails apply when you manage roles:
- Built-in roles can’t be renamed or deleted, and their permission sets are fixed. Create a custom role if you need a variation.
- You can’t delete a role that still has users assigned to it — reassign those people first.
- You can’t delete the role you’ve set as the auto-provisioning default. Change the default under Settings → Users first.
Creating and editing roles requires the roles:manage permission. Without it, the Roles page is read-only — useful for reviewing the access model during a security review even if you can’t change it.
Organization-level settings
Section titled “Organization-level settings”Beyond people and access, several pages under Settings configure how Sonora behaves for the whole workspace.
Settings → Organization is the workspace overview: your organization name, workspace URL, when it was created, and a summary of what Sonora holds — counts of customers, people, meetings, members, and the engagements and signals derived from them. It’s the page to land on for a quick read on the state of the workspace. Admins also manage the mailing address that appears in the footer of outbound emails here, which keeps promotional email compliant.
Settings → Custom fields lets you define extra fields on customer records beyond what Sonora and your integrations populate. Add a field, give it a name and type, and it becomes available across the customers table and in chat. This is how you bring workspace-specific attributes — a tier label, an internal account code — into Sonora’s data model. Managing custom fields requires the manage-settings permission.
Settings → Products & metrics is where you define the products customers use and the usage metrics tracked against them. Metrics can be computed from product events, giving Sonora a quantitative signal for health and engagement alongside the qualitative signals from conversations.
Settings → Note templates holds reusable templates for customer notes — a structured QBR outline, a save-play checklist — so notes stay consistent across the team. Anyone can use the templates; creating and editing them is an admin capability.
Your personal profile
Section titled “Your personal profile”Settings → Profile shows your own name and email address. It’s scoped to you, not the workspace, and it’s the one settings page every user can reach regardless of role.