Roles & Permissions
A Role is a set of Permissions a Team Member has access to. There are both default Roles, which can not be edited, and Custom Roles, which Team Members can create and customize.
Default Roles
The default roles that come with every account are: Admin User, Super User, Scheduled Call User, and Volunteer User. These Roles define a variety of common permission sets that an organization may need. You can see the Permissions that each Role has access to by visiting the Roles & Permissions section under Settings, and clicking on the Role.
Custom Roles
Depending on your Billing Plan, you can also create custom Roles to match precise Permission sets you want to grant a Team Member. Simply give your new role a name, and decide which Permissions to grant the Team Member, then save.

Cloning a Role
If you want to create a new role that is similar to an existing one, you can clone it rather than building from scratch. Cloning copies all of the existing role's permissions into a new, fully editable custom role.
To clone a role:
- Navigate to Settings → Roles & Permissions
- Click on the role you want to copy
- Click the Clone Role link near the bottom of the page
- Enter a name for the new role and click Clone Role
The new role appears immediately and can be edited like any other custom role. Cloning is available on plans that support custom roles, and you can only clone roles that fall within your own scope and permission level.
Tip: Cloning is useful when you need a role that is nearly identical to an existing one but with one or two permissions added or removed — for example, a version of your standard organizer role that also includes the ability to send email blasts.
Common Permission Scenarios
| Scenario | Permission Needed |
|---|---|
| Draft emails/texts but not send them | Enable "Draft" permissions, disable "Send" permissions |
| Send emails/texts | Enable both "Draft" and "Send" permissions |
| View contacts but not edit | Enable "View People", disable "Manage People" |
| Take event attendance | Enable "Manage Events" permission |
| Run phonebanks only | Assign "Volunteer" role (grants workflow access only) |
| Create new people or event tags | Enable "Add New Tags" permission |
| View protected contact fields (phone, email, address) | Enable "View Restricted Properties" permission. See Protected Core Fields |
| View and submit 10DLC brand registration and campaign verification | Enable "Manage 10DLC Compliance" permission |
| Log into the dashboard as another team member within your scope | Enable "Impersonate Team Members" permission |
| Allow a team member to connect an AI assistant (Claude, ChatGPT, Cursor) | Enable "Connect AI Assistants (MCP)" permission |
| Allow a connected AI assistant to add notes, edit tags/properties, save lists, or schedule tasks | Enable "AI Assistant Write Access" permission |
| Work the funnel queue and board, move people between stages, and claim rows | Enable "Work funnels" permission |
| Create and configure funnels, edit stages and rules, and reassign owners | Enable "Manage funnels" permission |
| Connect a personal email account for 1:1 email | Enable "Manage Connected Email Accounts" permission |
Tip: If someone says "I can't send my email blast," check their role's permissions first. They may have been granted draft permissions but not send permissions.
Impersonating Team Members
The Impersonate Team Members permission allows a Team Member to log into the dashboard as another team member within their scope. This is useful for troubleshooting, training, and support scenarios where you need to see exactly what another team member sees.
Important: All actions taken while impersonating are attributed to the team member being impersonated, not the person who initiated the impersonation session. Use this permission with care and only grant it to trusted administrators.
When impersonating, a banner is displayed at the top of the dashboard indicating which team member is being impersonated. You can end the session at any time by clicking Stop Impersonating in that banner.
AI Assistant Permissions
Two permissions control how Team Members can use AI assistants (such as Claude, ChatGPT, and Cursor) with Solidarity Tech:
- Connect AI Assistants (MCP) — Allows this Team Member to authorize an external AI assistant to access Solidarity Tech on their behalf. The assistant can only see what this person's Role can see in the dashboard. This permission is required before a Team Member can connect any AI assistant.
- AI Assistant Write Access — Allows this Team Member's connected AI assistants to make changes, including creating notes, editing tags and custom properties, saving lists, and scheduling follow-up tasks. Without this permission, connected assistants are read-only.
Note: Both permissions work together with the organization-wide AI assistant setting. Even if a Team Member has these permissions, AI assistant connections can be disabled or set to read-only at the organization level by an admin with both the Manage Integrations and Manage Chapter Structure permissions. See Settings → Chapter Structure on the root organization page.
Funnels Permissions
Two permissions control access to Funnels, and they only appear in the roles editor when Funnels are enabled for your organization:
- Work funnels — Allows this Team Member to view funnels, work the queue and board, move people between stages, and claim unassigned rows.
- Manage funnels — Allows this Team Member to create and configure funnels, edit stages and rules, change row membership, and reassign owners.
Connected Email Accounts Permission
The Manage Connected Email Accounts permission allows a Team Member to connect and disconnect personal email accounts for 1:1 email. This permission only appears in the roles editor when Connected Email Accounts are enabled for your organization.
Note: Every Team Member can disconnect their own account or edit their own signature regardless of whether they hold this permission. This permission gates connecting new accounts and disconnecting accounts belonging to other team members.
URL Parameters for Scope and Role Management
Solidarity Tech provides special URL parameters that allow administrators to manage user scope and role access dynamically.
Permanent Scope Changes
You can create URLs that permanently change a user's logged-in scope when they visit the link. This is useful for directing Team Members to specific organizational contexts or for administrative management.
Parameters:
change_scope_id: The ID of the target scope (Chapter or Organization)change_scope_type: Either "Chapter" or "Organization"
Example URLs:
https://dashboard.solidarity.tech/people?change_scope_id=123&change_scope_type=Chapter
https://dashboard.solidarity.tech/events?change_scope_id=456&change_scope_type=Organization
When a user visits a URL with these parameters, their scope will be permanently changed to the specified Chapter or Organization (assuming they have access to it). This change persists across their dashboard sessions until manually changed again.
Use Cases:
- Directing Team Members to work within a specific chapter context
- Administrative management of user scopes
- Onboarding Team Members to the correct organizational scope
Temporary Role Changes
The lia_role_id parameter allows administrators to temporarily view the dashboard with different role permissions for a single request. This is useful for testing what users with different permission levels can see and access.
Parameter:
lia_role_id: The hash ID of the role to temporarily assume
Finding the Role ID:
To get the role ID for custom roles:
- Navigate to Settings > Roles & Permissions
- Click on the role you want to test
- Copy the hash ID from the URL (the long string after
/roles/)
For example, if the role edit URL is:
https://dashboard.solidarity.tech/settings/roles/8TGIDx88PzcdNofDMApegsIhOedIr5ihTxb4Gl8Qmwc
The role ID would be: 8TGIDx88PzcdNofDMApegsIhOedIr5ihTxb4Gl8Qmwc
Example URL:
https://dashboard.solidarity.tech/people?lia_role_id=8TGIDx88PzcdNofDMApegsIhOedIr5ihTxb4Gl8Qmwc
Important Notes:
- Role changes are temporary and only apply to the single request
- You can only change to roles with equal or lower permissions than your current role
- The original role is restored after the page loads
- This feature is primarily for administrative testing and verification
Use Cases:
- Testing user experience for different permission levels
- Verifying what content is visible to specific roles
- Administrative troubleshooting and user support
Security Considerations
- Scope changes only work if the user has legitimate access to the target scope
- Role changes are restricted to equal or lower permission levels
- Both features require proper authentication and existing dashboard access
Updated 12 days ago
