Use named HostBill staff accounts and task-based privileges so support, billing and infrastructure teams receive the access their work needs. A person who answers tickets does not automatically need permission to refund invoices, reveal service passwords or terminate accounts.
01 Create and test a staff role
- Open Support > Staff Members. Review existing staff and teams before adding another account, especially if the person previously worked for your business.
- Choose Add Staff Member and enter the person's identity, work email and unique login credentials. Configure two-factor authentication when the relevant module is active.
- Assign the appropriate team or configure individual privileges. Review billing, support, provisioning, system configuration and security permissions separately.
- For a support role, start with the required ticket access and department responsibilities. Add billing or service visibility only where support needs it. Reserve actions such as refunds, account termination, password access and API management for authorised roles.
- Choose relevant notifications for the staff member or team. Notifications should point to an accountable operator; receiving an alert does not itself grant permission to perform the action.
- Test using the new account. Confirm one permitted workflow and one action that should be unavailable, without performing a destructive production operation.
02 Maintain the access model
Review both team assignments and individual exceptions when a person's duties change. Record why a sensitive permission was granted and who owns its review. Remove or disable access promptly when the person leaves, and consider separate integration credentials they may also control.
Common questions
Why can a staff member view an invoice but cannot refund it?
HostBill separates viewing and refund privileges. That separation supports a billing approval process. Check the person's authorised responsibilities before adding the missing permission.
Should every experienced technician receive full administrator access?
Base access on duties rather than seniority alone. A technician may need service diagnostics while another role handles financial adjustments and security configuration. Testing a narrow role exposes the exact missing capability without opening unrelated areas.