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.

1608

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:

  1. Navigate to Settings → Roles & Permissions
  2. Click on the role you want to copy
  3. Click the Clone Role link near the bottom of the page
  4. 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

ScenarioPermission Needed
Draft emails/texts but not send themEnable "Draft" permissions, disable "Send" permissions
Send emails/textsEnable both "Draft" and "Send" permissions
View contacts but not editEnable "View People", disable "Manage People"
Take event attendanceEnable "Manage Events" permission
Run phonebanks onlyAssign "Volunteer" role (grants workflow access only)
Create new people or event tagsEnable "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 verificationEnable "Manage 10DLC Compliance" permission
Log into the dashboard as another team member within your scopeEnable "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 tasksEnable "AI Assistant Write Access" permission
Work the funnel queue and board, move people between stages, and claim rowsEnable "Work funnels" permission
Create and configure funnels, edit stages and rules, and reassign ownersEnable "Manage funnels" permission
Connect a personal email account for 1:1 emailEnable "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:

  1. Navigate to Settings > Roles & Permissions
  2. Click on the role you want to test
  3. 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

Did this page help you?