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 (titled Users and roles) has four tabs — Users, Invites, Roles (ex. groups) and Auth History. Opening it requires the Manage users permission.
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.
| Category | Permission | What it controls |
| Account management | Manage users | Managing users, roles and permissions — that is, the Users and groups screen itself. |
| Manage subscription | Billing information, payment methods and purchases. | |
| API access | Viewing, editing and generating API access tokens. Also requires Personal data, because an API token can read the whole audience. | |
| Domain and email verification | Adding, verifying and editing domains and email addresses. | |
| Applications | See applications | Viewing application-related data. |
| Modify applications | Managing campaigns, push presets, test devices, configurations, events and deep links. | |
| Messages | See messages | Viewing messages. Important: this one is also required in order to send or delete messages, so grant it alongside the two below. |
| Send messages | Sending push notifications, emails, autopushes, geozones and RSS feeds. | |
| Approve messages | Review submitted push presets and email templates and approve or reject them. Only relevant when content approval is turned on for the account. | |
| Delete messages | Deleting messages from the system. | |
| Ad inventory | See email ads | Opening the Ad inventory screen to view campaigns and creatives. Only relevant when Ad slot is enabled for the account. |
| Modify email ads | Creating, editing and deleting campaigns and creatives in the Ad inventory. Without it the screen is read-only. | |
| Personal data | Personal data | Viewing and exporting the audience: devices, emails, phone numbers, HWIDs, user IDs and push tokens. Without it, the role can still create and send messages, but screens such as User Explorer, segment exports and recipient exports are unavailable. New roles do not have it by default; the default Admins role does. |
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.
Creating a role
- On the Roles (ex. groups) tab, click Add role.
- Enter a name in the Name field and tick the permissions the role should carry.
- Click Save. The role then appears in the list and can be assigned to users.
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 (ex. groups) 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.
Comments
0 comments
Please sign in to leave a comment.