User roles, permissions, and what they control

Overview

Pushwoosh lets your whole team work inside a single account. You invite sub-users and give each of them only the access their job needs — developers configure and test applications, marketers send messages and read statistics — and you can keep apps that are not ready for a wider audience out of everyone else's reach.

Everything to do with team access lives in one place: My Account → Users and groups. That screen has four tabs — Users, Invites, Roles and Auth History.

A note on naming: what used to be called a user group is now called a role. It is the same thing — a named set of permissions that you assign to people — only the label changed.

How access is put together

Access in Pushwoosh comes from two layers that stack on top of each other:

• Role permissions apply across the whole account. You create a role, tick the permissions it should carry, and assign users to it.
• App-specific permissions apply to one application only. You use them to open up a single app to someone who otherwise has no access to your applications.

The account owner

The account owner is not a role and cannot be edited like one. The owner always appears first in the Users list, their role cannot be changed, and their access cannot be revoked. Treat owner access as the master key to the account and hand it out accordingly.

Available permissions

When you create or edit a role, you pick from the following permissions.

The most common mistake here is granting Send messages on its own and expecting it to work. It will not — See messages is a prerequisite for both sending and deleting.

App-specific permissions

Use app-specific permissions when someone should reach one application rather than the whole account. They are configured per app, in the Application Permissions section of that application, and they grant three rights:

• See — the same access as See applications, but for this app only.
• Modify — the same access as Modify applications, but for this app only.
• Send — the ability to send messages to this app only.

App-specific permissions work even when the role has no account-wide application access at all. If a role does not have See applications enabled, but application X grants that role the See right, then people in that role will see application X and nothing else. This is what makes it possible to hand a contractor a single app without exposing the rest of your account.

Inviting a user

• Go to My Account → Users and groups and click Invite user.
• Pick a Role. If the dropdown is empty, you need to create a role first — the invite cannot be sent without one.
• Enter the person's email address and click Send invite.
• They receive an email with a verification link. After following it they sign up or sign in (signing in with Google works too) and land in the account automatically.

Invitations show up in the Invites list with a status of Sent or Accepted. If an invitation did not arrive, you can Re-send it after an hour. To withdraw one, open the three-dot menu next to the invitee's email and choose Revoke access.

Managing roles

The Roles tab lists every role with the number of users assigned to it. The three-dot menu (⋮) next to a role is where all of its management lives:

• Edit permissions — change which boxes are ticked, then save.
• Manage members — select or deselect users to add or remove them from the role, then click Apply.
• Delete role — if anyone is still assigned to it, you will be asked to pick another role to move them to first, so nobody is left without one.

Auth History

The Auth History tab logs recent sign-in activity for everyone on the account: user email, whether the attempt succeeded or failed, the originating IP address and a timestamp. You can filter it by email. It is the first place to look if you suspect access you did not expect.

Securing sub-user access

Permissions decide what someone can do; they do not decide whether the account is safe. Set up Two-factor authentication for sub-users, or passkeys, so that a leaked password on its own is not enough to get in.

For the full walkthrough with screenshots, see Manage user access and permissions in the Pushwoosh documentation.