When you add team members to your Rackwave account, you can control which platform dashboards (MigoSMTP, Telnxo) they can access via SSO and what they can do once inside. This article explains how platform access is granted, how to restrict it per user, and best practices for access governance.
How Platform Access Works for Team Members
Platform access in Rackwave is governed at two levels:
- Portal-level role — determines whether a team member can see the platform service card and click Access Platform in the portal.
- Platform-level role — determines what the team member can do inside the platform (MigoSMTP or Telnxo) once they log in via SSO.
Key point: Portal role controls whether someone can access a platform. Platform role controls what they can do inside it. Both must be configured correctly for your team members to work effectively.
Which Portal Roles Get Platform Access?
| Portal Role | Can Access Platform via SSO? | Default Platform Role Assigned |
|---|---|---|
| Owner | ✓ All platforms | Admin / Owner on platform |
| Admin | ✓ All platforms | Admin on platform |
| Standard User | ✓ Assigned platforms only | Member / Operator on platform |
| Billing Contact | ✗ No platform access | None |
| Read Only | ✓ View-only on platform | Viewer on platform |
Granting a Standard User Access to a Specific Platform
Standard Users do not automatically receive access to all platforms. Access must be explicitly granted per platform:
- Go to Team Members in your Rackwave account settings.
- Click on the Standard User's name to open their profile.
- Scroll to the Platform Access section.
- You will see a list of all active platform subscriptions (MigoSMTP, Telnxo, etc.).
- Toggle Enable Access for the platform(s) you want to grant.
- Optionally set their platform-level role for each (e.g. Operator, Member, Viewer).
- Click Save Changes.
Platform-Level Roles Inside MigoSMTP
| Role | Can Do | Cannot Do |
|---|---|---|
| Admin | Everything — manage domains, SMTP accounts, API keys, suppression lists, view all reports | Delete workspace (Owner only) |
| Operator | Send emails, manage templates, view delivery reports, manage suppression lists | Create/delete SMTP accounts, manage domains, view API keys |
| Viewer | View dashboard, delivery reports, and analytics | Send emails, change settings, access API keys or SMTP credentials |
Platform-Level Roles Inside Telnxo
| Role | Can Do | Cannot Do |
|---|---|---|
| Admin | Full access — manage channels, API keys, templates, DLT settings, campaigns, reports | Delete workspace (Owner only) |
| Operator | Send SMS / Voice / WhatsApp, manage templates and campaigns, view message logs | Manage API keys, change sender IDs, access DLT settings |
| Viewer | View dashboard, reports, and campaign analytics | Send messages, change any settings, access API keys |
Revoking Platform Access from a Team Member
- Go to Team Members.
- Open the team member's profile.
- In the Platform Access section, toggle off the platform you want to revoke.
- Click Save Changes.
- The member's SSO access to that platform is revoked immediately — their next click on Access Platform will be denied.
Active sessions: Revoking platform access does not immediately terminate an existing active session on the platform. The member will lose access on their next login attempt or session expiry. If immediate termination is required, contact support to force a session invalidation.
Access Governance Best Practices
- Principle of least privilege — only grant the platform access and role level that a team member actually needs for their job. Avoid assigning Admin roles unless necessary.
- Review access quarterly — periodically audit who has access to each platform and remove access for anyone who no longer needs it.
- Offboard promptly — when a team member leaves, remove their portal access and revoke platform access on their last day.
- Separate credentials — never share a single set of SMTP credentials or API keys between multiple team members. Each person should have their own access.
- Use Viewer roles for reporting — team members who only need to see analytics should be assigned Viewer roles to prevent accidental configuration changes.