Use one account for one person
A practice login should belong to one named person. That person signs in with their own email, keeps their own password private, and completes work under their own account.
This gives ordinary actions an owner. If an appointment moves, a form is opened, or a setting changes, you have a useful place to start when you need context. You can ask the person who was signed in instead of asking the whole team to remember who used the shared desk that afternoon.
Named accounts also make removal cleaner. When someone leaves, takes a long break, or no longer needs the system, you can revoke one person's access without changing a shared password and wondering which devices still have it saved.
The rule can be one sentence in your operations guide:
Use only your own practice account. Do not share passwords or work from another person's signed-in session.
Keep the wording direct. This is a normal work boundary, not an accusation.
Match access to the job someone actually does
An individual login does not mean every person needs the same access.
Start with the work, not the job title. Write down the actions someone must complete during an ordinary week. A scheduler may need to view the shared calendar, create and move appointments, and answer practical booking questions. A practitioner may need their schedule, assigned client records, forms, and clinical documentation. An administrator may need broader settings and team-management access.
Then choose the narrowest role that supports those actions. Do not grant broader access because it feels easier than checking the workflow. Broad access can expose information the person does not need and make an accidental change more likely.
Use a short role note for each person:
- the work they are responsible for;
- the system role they have;
- any task they must pass to someone else; and
- the date the access was last reviewed.
This note is more useful than a copied permissions chart. It connects access to real work and gives you something concrete to revisit later.
Set up the login before the first real task
Do not make a client-facing appointment, payment, or record the test of whether a new account works.
Send the invitation before the first shift when possible. Ask the team member to accept it, sign in, and confirm they can reach the pages their role requires. Use an approved demo environment, an obviously fictional record, or a verbal walkthrough for the first practice task. Do not copy a real client's details into a training example.
Check three things:
- The invitation reached the intended email address.
- The person can sign in through the normal route.
- Their role lets them complete the expected work and stops them where it should.
If something is missing, fix the role or the workflow. Do not lend them another person's session for the day. A setup problem is useful information. A borrowed login only hides it until the next shift.
Make shared workstations behave like shared space
A front desk computer can be shared. The account open on it should not be.
Give each person a separate browser or operating-system profile when your setup supports it. At minimum, require a full sign-out at the end of a shift and a fresh sign-in for the next person. Browser profiles should have clear names and should not save another team member's password for general use.
Add the handoff to the physical routine:
- finish or flag open work;
- close client records;
- sign out of the practice account;
- lock the computer; and
- leave the next person a privacy-safe status note.
Avoid notes such as "client with anxiety called again" on a desk pad or shared task. The handoff usually needs an action and an owner, not clinical detail. Put sensitive information in the client record or other approved clinical workflow.
If people regularly find someone else's session open, treat that as a process problem. Check whether sign-out is too hidden, shifts overlap without a handoff, or the workstation does not lock quickly enough. Repeating the rule will not fix a setup that makes the wrong action easier.
Review access when the work changes
Access should change when responsibility changes, not months later when someone remembers.
Build a review into a few predictable moments:
- a person joins the practice;
- a team member moves into a different role;
- a contractor's project ends;
- someone begins or returns from an extended leave;
- a practitioner stops working at one location; or
- a person leaves the practice.
Ask what they need now, not what they used to need. A practitioner who takes on scheduling may need a different role. Someone stepping away from administrative work may need less access even if they remain part of the practice.
When a person leaves, revoke their login promptly. Do not delete or rewrite past records simply to remove access. The practice may still need appointment history, documentation, and an accurate record of who completed earlier work. Removing the ability to sign in is a different action from erasing the work that was properly recorded.
Make one person responsible for this review. If ownership is vague, offboarding tasks tend to sit between the practice owner, office manager, and whoever manages the software.
Run a ten-minute account review each quarter
Staff changes are not the only source of drift. Temporary access becomes permanent. A role expands. A second email is added during troubleshooting and never revisited.
Once each quarter, open your current team list and ask:
- Does every active account belong to someone who still works with the practice?
- Does each person's role match their current responsibilities?
- Are any invitations still pending or tied to an outdated email?
- Does anyone have broader access than their work requires?
- Is there a shared password or signed-in browser session still acting as a shortcut?
Record the date and any action you took. You do not need a long report. A line such as "September access review completed; scheduler role removed from one former contractor" is enough to show what was checked.
If you find an account you do not recognize, do not guess. Confirm the email, the person it was meant for, and recent activity through your normal support and security process. Remove access when it is clearly no longer authorized.
Keep the rule practical enough to follow
People share logins because the shared route appears faster. Your job is to make the named route just as ordinary.
Send invitations early. Use roles that match real work. Keep password resets simple. Put sign-out into the shift handoff. Give the team one clear place to report missing access without embarrassment or delay.
You do not need to make every account perfect in one afternoon. Start by replacing the shared login used most often, then review the rest of the team. The important change is that each person has a clear route into the work and you have a clear way to close that route when it is no longer needed.
If you manage a team in Stillpoint, owners and admins can invite practitioners with admin, practitioner, or scheduler access, then revoke that login later. Stillpoint's privacy and security tools also give owners and admins a PHI access audit log, so named accounts make those records far more useful when you need to understand what happened.
