The staff portal is a standalone front-end page where an employee signs in with their own email and password to work their calendar and bookings, without ever seeing wp-admin or holding a WordPress account. It is in the free wordpress.org plugin.
Where:
/portal/staffby default, configurable at Settings → General → Portal Access → Employee Portal. Access is granted on the employee record under Employees.
Giving someone access
Portal access is a property of the employee, not a WordPress user. Open the person under Employees and set a password on their record; the Has password and Portal enabled states show whether it is live. An employee with no password set cannot sign in at all — the login refuses with a message telling them to ask an admin, rather than pretending the credentials were wrong.
Passwords must be at least eight characters and are hashed with WordPress’s own password functions, so nothing weaker than a WordPress login is in play. Only a site administrator can set or change one; there is no self-service reset from the portal, so a member of staff who forgets theirs asks you for a new one.
Signing in
Staff go to your portal URL and enter their employee email address and password. A successful login stores a server-side session and mirrors the token to an HttpOnly cookie that lasts fourteen days.
Repeated failures on one account are locked out: after eight consecutive wrong passwords, further attempts on that account are refused for fifteen minutes. Both numbers are adjustable under Settings → Security, and a correct password clears the counter immediately. The lockout is per account, so one person fat-fingering their password never locks out the rest of your team.
What the portal looks like
The portal is a standalone page, not a page in your theme. It deliberately strips every stylesheet and script that is not the plugin’s own, so it looks the same for everyone regardless of which theme you run and cannot be broken by theme CSS.
Inside, staff get the same screens administrators use — the same bookings list, the same availability editor — inside a portal shell, with the navigation filtered to what their role may view and the data filtered on the server.
Roles and what each can do
Every employee carries a portal role. Permissions are a grid of role × page × action, where the pages are Dashboard, Bookings, Services, Employees and Availability, and the actions are View, Add, Edit and Delete. Edit the grid under Settings → Roles & Permissions. The defaults are:
- Owner — everything, on every page.
- Manager — everything except deleting services and employees, which stays with the owner.
- Specialist — their own work only. They can view the dashboard, and view and edit their own bookings and availability. Services and employees are closed to them entirely.
- Receptionist — handles bookings for everyone, with no service or employee management.
Scoping is enforced on the server
Hiding a menu item is not the protection here. A staff session may only reach the appointment collections — services, employees, bookings, availability and holidays — and every other collection is refused outright. A specialist is filtered further, to bookings and availability that are actually theirs. Customer records, the full CRM, settings and any other engine’s data are not reachable from a portal session at all.
Profile and avatar
Staff can upload their own profile picture from inside the portal; it is written to their employee record. Because the portal is a front-end page, the WordPress media picker is not available there — the uploader posts the file directly.
Changing the portal URL
Under Settings → General → Portal Access you can move the employee portal to any path you like. The page is served directly by the plugin at whatever path you set — you do not create a WordPress page for it, and you should not. The Hotel user portal, which ships with the Pro add-on, is configured on the same card and defaults to /portal/hotel.
Troubleshooting
A member of staff can’t sign in.
Check that their record has a password set. Portal access is off until one exists, and the login says so rather than reporting bad credentials. Confirm too that they are using the email address on the employee record.
Sign-in is being refused after several attempts.
That account has hit the failed-login lockout. Wait out the window (fifteen minutes by default) or adjust it under Settings → Security. Setting a fresh password for them also lets them straight back in.
A specialist can only see some bookings.
That is the role working as intended — specialists see their own work. Move them to Receptionist or Manager if they need the whole calendar.
The portal page looks unstyled or shows my theme’s header.
The portal strips non-plugin assets by design. If your theme’s chrome is appearing, you are probably looking at a WordPress page you created at that path rather than the plugin’s own portal route — delete the page and let the plugin serve the URL.
The portal says it is not available on this site.
Portals are switched off for this install. They ship in every build and work fully, so this is a configuration state rather than a missing feature.