Deactivating a secondary SiteWorx user stops the intended panel access while preserving a reversible account record. Complete a separate credential inventory because FTP, SSH and application access may not depend solely on that panel identity.
IN THIS ARTICLE
01 What you need before you begin
Confirm the departing user’s exact login email and preserve required handover information. Ensure another authorised administrator can maintain the domains and recover the account.
02 Deactivate a SiteWorx user while preserving the account
- Open Administration > User Accounts and review the target user’s permissions and locked-domain scope.
- Select only that user, choose Deactivate from the selected-action menu and confirm. Avoid the select-all checkbox.
- Review separate FTP accounts, SSH keys, mailbox credentials and application administrators used by the person. Revoke or rotate the relevant independent access.
- Test a new panel login where appropriate and verify remaining authorised users still work.
- After the retention and handover period, delete the secondary record if permanent removal is required. Keep a record of the access changes.
03 Confirm the expected result
The retired identity should no longer provide the intended access, while websites and retained data continue operating. Each independent credential should have an explicit disposition.
04 Troubleshoot unexpected results
If deactivation was mistaken, use the supported Activate action for the exact user after reviewing permissions. Deleting a secondary user and deleting the entire SiteWorx account are very different actions; read the confirmation scope carefully.
05 Example: retire a panel user without deleting the website
A secondary SiteWorx user may have access to several domains even when their current task involves only one. Review the user's permissions and domain restrictions before deactivation so you understand the access being removed.
Ensure another authorised person can still administer the account. Then use the supported user-management control to disable or remove the intended secondary access. Do not confuse a user record with the hosting account or domain itself. Deleting the wrong object can affect far more than the person's login.
What else should I review?
Check separately for FTP accounts, application users, API credentials and shared secrets the person used. Deactivating a panel login should not be treated as proof that every other access route is closed. Rotate shared credentials where appropriate, while updating the legitimate services that depend on them.
Record what was changed and test with a new session. If a former user still appears able to act, preserve the time and affected operation and contact our support team. Avoid changing unrelated access settings repeatedly while investigating. The aim is to remove the retired person's access while leaving the website and authorised team working.
Is changing the master password enough?
No. A secondary identity and separate service credentials can continue to exist independently. Offboarding is complete only after every relevant access route is reviewed.