Why Can't Your "Admin" See Invoices?
Last night, one of the customers called saying their team admin wants to buy a new service but can't see any button to do so. It's not that they lack permission — the purchase option simply isn't rendered in their panel at all. This is exactly where account roles in ServerNet come into play, and if you don't know the difference, you'll end up stuck on the phone one day explaining why the account "Admin" isn't actually the real admin for purchases.
In ServerNet, each account can have multiple roles: Owner, Admin, Billing, and Support. Each role has a specific set of permissions that aren't randomly assigned. This article provides a detailed table for each role so you know who can purchase, cancel, view passwords, or access invoices.
The Four Main Roles and Their Access Boundaries
User roles in ServerNet are designed based on the principle of least privilege. That means no role sees everything by default. Save this table for yourself:
| Action | Owner | Admin | Billing | Support |
|---|---|---|---|---|
| Purchase new service | ✔ | ✔ | ✘ | ✘ |
| Cancel service | ✔ | ✘ | ✘ | ✘ |
| View service passwords | ✔ | ✔ | ✘ | ✘ |
| View and download invoices | ✔ | ✘ | ✔ | ✘ |
| Change main account password | ✔ | ✘ | ✘ | ✘ |
| Submit support tickets | ✔ | ✔ | ✔ | ✔ |
| Manage users and roles | ✔ | ✘ | ✘ | ✘ |
| Change service plan (upgrade/downgrade) | ✔ | ✔ | ✘ | ✘ |
| Access API and access keys | ✔ | ✔ | ✘ | ✘ |
Important note: The Owner is the only role that can delete the account or transfer ownership to someone else. If your company has only one admin and they become unavailable, you'll essentially hit a dead end.
Why Is Service Cancellation Owner-Only?
Canceling a service is an irreversible action. If an Admin or Billing user could cancel a service, a simple mistake could destroy your entire infrastructure. ServerNet deliberately gives this permission only to the Owner. If the Owner is unavailable and there's an urgent need to cancel, you'll have to go through identity verification via a support ticket — and that process takes time.
This is where people make mistakes: many teams make everyone an "Admin" to speed things up. The result? An Admin who thinks they can cancel a service doesn't see the button, opens a ticket, and the support team can't do anything because their role doesn't allow it. This isn't a bug or a limitation — it's by design.
The Billing Role: Financial Only, Not Technical
The Billing role is built for someone responsible for payments and invoice reconciliation but who shouldn't have access to service passwords. This role can view invoices, download them, and change payment methods. However, they cannot see MySQL or FTP passwords, even for the very service their invoice was issued for.
This separation is crucial in practice. If your accountant is also a developer, create two separate roles for them. A single user can have both the Billing and Admin roles — these combine, and their access will be a mix of both.
Who Can View Passwords?
Viewing service passwords (such as SSH or database passwords) is restricted to the Owner and Admin roles. This access is logged in the account's security log, and if someone views a password, a trace remains. For sensitive services, I recommend changing passwords after the first login — the password you see in the panel may have been viewed by any Admin.
If your team is large and has multiple Admins, the solution is to create a separate SSH key for each Admin and restrict root access. This is done at the service level, not at the account role level.
Managing Roles: Who Makes Someone an Admin?
Only the Owner can change user roles or add a new user to the account. Admins cannot create other Admins. This simple rule prevents the "Admins vs. Admins" scenario — one that really happens in large companies.
To add a new user, go to the "User Management" section in the user panel and enter their email. An invitation will be sent to their email, and they must confirm it. Until they confirm, they have no role and zero access.
No Custom Roles Available
ServerNet currently does not offer custom roles. You have four fixed roles and must work with them. If you need someone to manage only a specific service, you'll have to make them an Admin and accept that they'll have access to all services. Keep this limitation in mind — some competitors offer custom roles with granular access, but ServerNet does not.
If this limitation is too costly for you, here's an alternative: create separate accounts for separate projects. One account for each client or independent project, with its own Owner. Yes, managing multiple accounts is a hassle, but it creates a clean security boundary that no custom role could match.
Real-World Scenario: A Five-Person Team with Three Roles
Imagine you have a five-person team: a technical manager (Owner), two developers (Admin), an accountant (Billing), and a support agent (Support). This combination works well in practice:
- Developers purchase new services, view passwords, and submit technical tickets.
- The accountant downloads invoices and handles payments but has no access to servers.
- The support agent can only submit tickets — they can't even see service status.
- The technical manager (Owner) is the only one who can cancel a service or change someone's role.
Now, what if the technical manager goes on leave and one of the developers urgently needs to cancel a service? They'll have to wait or contact support and go through the identity verification process. This is the price you pay for security. If this cost is too high for you, you can make a second technical manager an Owner as well — having two Owners is allowed.
Account Roles vs. Service-Level Access
A subtle point: account roles in ServerNet determine what you see in the user panel. However, access to the service itself (like SSH or cPanel) is managed by passwords and keys that are independent of the account role. In other words, a user with the Support role could have an SSH password from another source (e.g., from a previous manager) and log directly into the server. The account role doesn't prevent this.
To close this security gap, you should change passwords after any role change in your team. This is an operational practice that isn't in the official documentation, but anyone who has experienced it once won't repeat the mistake.
Frequently Asked Questions
Can an Admin cancel a service?
No. Service cancellation is exclusively available to the Owner role. If an Admin wants to cancel a service, they won't see the cancel button in the panel and must ask the Owner to do it. This restriction is intentional to prevent accidental cancellations.
How do I change a user's role?
Only the account Owner can change user roles. Go to the "User Management" section in the user panel, find the user, and select the new role from the dropdown menu. The role change takes effect immediately, and the user will see their new permissions on their next login.
Can I have two roles for one user?
Yes. Roles combine. If a user is both an Admin and Billing, they'll have the combined access of both roles — they can purchase services, view passwords, and download invoices. The only role that cannot be combined with any other is Owner.
Who can view account invoices?
The Owner and Billing roles can view and download invoices. Admins and Support users have no access to invoices. If someone on your team needs to see invoices but shouldn't have access to service passwords, the Billing role is the right fit for them.
Before adding your team to the panel, take a minute to think: if the account Owner becomes unavailable today, who can manage the services? If the answer is "no one," designate a second Owner. This is a five-minute action that can prevent a full-blown crisis in the future. To get started, you can use ServerNet's documentation and knowledge base to structure your team based on the roles table. If you're unsure which service suits your team, check out the service selection guide. And if you're looking for a service with simple management and a clear user panel, ServerNet's Linux hosting is a great place to start — account roles work the same across all services, so learn this structure once and use it forever.