Team Members

Invites and access

The Team Members page lets you invite collaborators to work inside one or more of your workspaces. Each invite is tracked with an explicit status — pending or joined — so you can see who has accepted and who still has an outstanding invitation.

To invite a new team member, click Invite member, enter their email address, assign them to one or more workspaces, and configure the permissions for each workspace. Mailrith sends the invite email automatically — the invitee receives a link to accept and create their account or log in.

Invitations that remain pending can be resent if the original email was missed. You can also cancel a pending invite if the person should no longer be given access.

Permission model

Mailrith permissions are feature-specific. Rather than a broad "admin" or "viewer" role applied to everything, you can configure what each team member can do for each feature area within each workspace they are assigned to.

For each feature area, you can grant one of two access levels:

• View: the member can see the data in this area but cannot create, edit, or delete anything.
• Manage: the member has full read and write access — they can create, edit, and delete in this area.

Feature areas with granular permission control include:

• Subscribers and audience data
• Forms
• Broadcasts
• Sequences and automations
• Email delivery connections
• Team member management

This granularity makes it practical to give a copywriter manage access to broadcasts without granting them access to delivery configuration or subscriber data. Or to give a client view access to broadcast analytics without letting them modify the audience.

Editing and removing members

Permissions can be updated after a member has joined. If a team member's responsibilities change — for example, they take on campaign management in addition to their original scope — open their record and adjust the permissions accordingly. Changes take effect immediately.

When a team member no longer needs access — they've changed roles, left the organization, or completed a project — remove them from the workspace rather than leaving their permissions active. Mailrith removes their access immediately upon confirmation.

Removing a team member does not affect any content they created — broadcasts, forms, or other work they built remain in the workspace. Only their access is revoked.

Recommended setup

• Grant manage access only to what a team member actively uses. Excess permissions create unnecessary risk — a team member who only sends broadcasts does not need manage access to delivery connections or team settings.
• Keep billing and high-impact settings with the account owner. Team members do not have access to billing by default; keep it that way unless there is a specific reason to share it.
• Use separate workspaces when teams should not see each other's audiences. Permissions control what a member can do within a workspace, but if two teams should have no visibility into each other's data at all, separate workspaces provide a cleaner boundary than permissions alone.
• Review team member access periodically. As projects end and roles evolve, stale permissions accumulate. A quarterly review of who has access to what keeps your workspace access model clean.