Pomio CRM is built around named users: each person is invited by email, gets their own role and scope, and can protect their own login with an authenticator app. A shared account undoes most of that.
Why teams fall back on shared logins
Shared logins usually start with good intentions: one account for the front desk, a temporary login for an intern, or a generic “sales” user so nobody has to wait for an invite. It feels cheaper and faster. The cost shows up later, when nobody can say who moved a deal, deleted a contact or exported a list.
What a shared login breaks
Ownership stops meaning anything when three people act as the same user; see a single owner on every open CRM deal. The audit trail records the account, not the person, so “who changed this?” has no answer. Role permissions collapse to the widest need of anyone who uses the account, which defeats own, team and tenant scope. Two-factor authentication becomes awkward because the code lives on one person’s phone, so teams quietly switch it off; see whether a CRM needs multi-factor authentication.
Offboarding is where it really hurts
When someone with a personal login leaves, an admin blocks that one account and reassigns their open work; see reassigning open CRM deals when an owner leaves. When someone with a shared login leaves, the only safe step is to change the password for everyone who still uses it, and hope nobody wrote it down somewhere. In practice that step is often skipped, and a former colleague keeps access to customer data.
Integrations and automations
If a tool or automation needs access to CRM data, do not let it borrow a person’s login. Give it its own clearly named account with only the permissions it needs, so its changes are recognisable in the history and its access can be removed without locking out a colleague.
How Pomio CRM supports one login per person
Admins invite people by email and assign role permissions with an own, team or organisation scope. Users can protect their personal account with authenticator-based two-factor authentication and reset their own password. When a login looks wrong or someone leaves, an admin can block the account and restore it later, and the audit log keeps actions attributable to a named user.
A practical login checklist
Before each access review: list every active account and match it to one named person; remove or rename generic accounts such as “sales” or “office”; confirm each person’s role and scope fit their actual work; turn on two-factor authentication for personal accounts; block accounts of people who left and reassign their open deals; give integrations their own named account instead of a person’s login.
Go deeper
Is a shared login acceptable for a temporary worker?
No. Invite the temporary worker as their own user with a narrow role, then block the account when the assignment ends. That is faster to clean up than rotating a shared password.
Is paying for an extra seat worth it?
Usually yes. A named seat keeps ownership, permissions and the audit trail honest. The cleanup after an untraceable change or a leaked shared password tends to cost more time than the seat.
Can two-factor authentication work on a shared account?
Only badly. The code sits on one device, so others either depend on that person or the second factor gets disabled. Personal accounts are the setup two-factor authentication is designed for.
Does Pomio CRM decide who gets an account?
No. Your admins decide who is invited and which role each person gets. Pomio CRM keeps those choices visible per user and records actions in the audit log.