Users, security & logging in
In this chapter - Logging in and choosing a database - Signing in to the web portal (www.techiecrm.com): timeouts, "keep me signed in", signing out - Users in TechieCRM - User-management rights — what they now gate - Access rights that are enforced today — including what unticking Read in the web portal's Security Groups now does - The Administrator window - Not yet available
Logging in
Login credentials: the dialog has four fields — Database Server, Client Database, User ID and
Password. Server and Client Database are chosen with the … browse button, which opens
Open Database Server. That dialog's Source CRM selector at the top picks the source —
Source CRM (SQL) or MongoDB (local) — and the list beneath shows the databases you have
opened before as soon as it opens (in SQL mode your last login is always listed; in MongoDB mode
it lists the local server's databases, TechieCRM ones marked ✓). Pick one and click Open to fill
the login fields (it also sets the source mode for you). Browse (SQL) opens Connect Database
to add one via SQL Server discovery; in MongoDB mode Browse becomes Refresh to rescan.
Remove drops a saved SQL database (it never deletes a local Mongo database). The last
server/database/user are remembered (never the password) — and every successful login is saved to the
list. Errors are specific (invalid user id, wrong password, cannot access database, server
unreachable) and return you to the field. Spaces accidentally copied in front of or behind the
User ID are ignored, so a pasted id is not rejected as invalid for whitespace alone. If the
server drops after login you get a friendly retry.
main.py starts the CRM; administrator.py starts the Administrator window with the same login;
inside the CRM, Setup ▸ Administrator opens it on the current connection.
Signing in to the web portal (www.techiecrm.com)
Your cloud workspace uses your email + password (set from the invitation link).
Your invitation link
When your workspace is approved you get an emailed link that lets you choose a password. It works once, and it stays valid for 14 days. If it doesn't work, the page tells you which of the three ordinary things happened, and what to do:
| What the page says | What happened | What to do |
|---|---|---|
| This invitation has already been used | The password was set — usually by you, earlier. | Click Sign in. Forgotten it? Use Forgot password there. |
| This invitation link has expired | It is more than 14 days old. Nothing is lost; the workspace is still there. | Click Ask for a new invitation — an administrator re-issues it. |
| This invitation link is incomplete | Only part of the link opened — some email programs split long links across two lines. | Go back to the email and copy the whole link, or ask for a fresh one. |
Administrators: Admin Portal ▸ Registrations has both Resend invite and Show invite link (the second is the fallback when the email doesn't arrive — pass the link on securely). "Show invite link" is only offered while the person has not yet set a password. - Idle timeout (default). For security you are signed out automatically after 15 minutes of inactivity. Every click or keystroke extends the session; one minute before the limit the app shows a "Still there? … Stay signed in" prompt. If you come back later you'll see "you were signed out after 15 minutes of inactivity" on the login page — just sign in again and you return to the page you were on. - Keep me signed in on this computer (checkbox on the login form) — keeps you signed in on that browser for up to 14 days of use (still sliding: two weeks without a visit ends it), and remembers your email on the login form. Only tick it on your own computer. - Sign out — from your name/menu (top-right) in the CRM, or the Sign out link on techiecrm.com when you're already signed in. The sign-out page has "Forget my credentials on this computer" (unticked by default): ticked, it clears your saved email, any "keep me signed in" and everything TechieCRM stored in that browser — always tick it on a shared or public computer. Untucked, the login page keeps your email prefilled next time. - Passwords are never stored in the browser by TechieCRM (only your browser's own password manager, if you choose to use it).
Users
The source CRM's login users appear in the Clients list under the organization row (your own company; both have their own icons — a building for the organization, and a person for each login user, with a small key mark on the icon for logins that hold administrator (user-management) rights). View ▸ Filter ▸ Users shows only them and switches the list to the *Users column setup (Name / Position / Company / Email Address / Phone 1 / City — created the first time; user rows fill whatever column setup is active by column name). Selecting a user drives the two lower panels like a client would: Related lists the organization row and the other users (open one to see it; the organization row opens the org chart), Interactions lists what that user owns — their notes, documents and e-mails, their To-Do tasks and the meetings on their calendar. Right-click a user: Open (User Properties) — a client-style dialog (field names as placeholders and tooltips, two rows of tabs): General (name/position, company/address, internet, phones), User-Defined Fields (live), Activities (the user's tasks and meetings, with the same filters/actions as a client's Activities), Access Rights (the user's effective rights per module — read, insert, modify, delete — as the source CRM computes them; read-only), Groups / Teams (the security groups the user belongs to), Windows Authentication (not available); Message… (opens a conversation with that user), Org Chart (users nested by Reports to), Disable Login / Enable Login (see below), Change Password… (placeholder — the working one is Change Password… in your own name menu, top right, which asks for your current password), Preferences… (placeholder), Add User… (opens the form; creation itself stays in the source CRM's Administrator — see below). There is no Delete on this menu — see Disabling a user login. User display names everywhere come from the source CRM's user details. From the Clients list the dialog is view-only; editing is done in the Administrator's Manage Users (A4).
Disabling a user login
A user is a login, not an address-book entry, so TechieCRM never deletes one — the user right-click menu (Clients list or Related panel) has no Delete. It carries Disable Login instead, and Enable Login once the account is off. Disabling asks you to confirm, then switches the account off: the person can no longer sign in, the account is marked disabled everywhere TechieCRM shows it, every record they own stays exactly where it is, and the login can be switched back on at any time from the same menu. The Administrator's Manage Users page (A4) shows and changes the same state.
At the sign-in screen (new, September 2026). A disabled login is now stopped when it tries to sign in to the desktop app, not merely marked. The password box is checked first — the database still has to accept it — and then TechieCRM asks whether that user has been disabled. If it has, the sign-in is refused with "Login disabled", naming who can undo it, and nothing about the session changes: the login screen stays open for somebody else to sign in, and if the app was already open as another user it keeps the database it had. "Enabled (web off)" still signs in to the desktop — that setting only closes the web portal.
Deleting a login — the ADMN_Users records, the access rights and group memberships, and
the SQL login behind them — is done in the source CRM's Administrator, not here. MASTER is the
built-in administrator and can never be disabled; the menu item is greyed out for it. Enabling or
disabling a login needs user-management rights on your own login.
User-management rights — what they now gate
Everything that changes another login is checked against the user-management right of the login you signed in with (the source CRM's Users right, the same one that puts the small key mark on a person icon in the Clients list). MASTER always passes. Without it you are told "Not permitted for your user ID" and nothing is written:
| Action | Where | Right needed |
|---|---|---|
| Disable Login / Enable Login | Clients list right-click menu, and Administrator ▸ Manage Users | insert or modify |
| Editing a user's General tab (name, company, address, e-mail, phones) and pressing OK | Administrator ▸ Manage Users ▸ open a user | insert or modify |
| Add Member… to a security group | Administrator ▸ Security Groups & Teams | insert or modify |
| Remove Member from a security group | Administrator ▸ Security Groups & Teams | delete |
One thing this does not do: it does not hide the menu items or the Administrator pages — you can still open them and read everything; the refusal happens when you try to save.
These rights and the sign-in check are separate questions and are answered in separate places. The rights above decide what a signed-in user may change about other users; Disable Login decides whether a user may sign in at all, and is enforced at the login screen (see Disabling a user login above). Deleting the SQL Server login itself is still the belt-and-braces way to lock somebody out of the database as well as out of TechieCRM, and is done in the source CRM.
(New in this release: before it, these four actions were not checked at all — any signed-in user could disable another administrator's login. If you rely on that, re-check who holds the user-management right in Manage Users ▸ Access Rights.)
When the database can't be read
A refusal to save is not the same thing as a database that could not answer, and from the September 2026 update the two no longer look alike:
- Editing a user and pressing OK. If TechieCRM cannot read the shape of the user table (the connection dropped, or your sign-in isn't allowed to read the database catalogue), you now get "The user could not be saved" with the reason, and the dialog stays open so your typing is not lost. Before, the save quietly wrote nothing and reported "Nothing could be written — no editable field matched a column", which sounds like you filled the form in wrongly.
- Security Groups & Teams. A database with no security groups shows "No security groups in this database." A database that could not be asked shows "Groups could not be read: …" with the reason, instead of the same reassuring "none".
- The sign-in check. If TechieCRM cannot find out whether your login is enabled — the user has no record in the source CRM's user table, the connection dropped between proving your password and asking the question, or the setting holds a value TechieCRM does not recognise — you are let in, and told once: "Login state could not be checked", with the reason. That direction is deliberate. "We could not find out" is not the same answer as "you are disabled", and treating it as one would lock an entire company out of a database over a momentary fault. If you were relying on Disable Login to keep somebody out and you see that message, disable their SQL Server login too and have the user record checked in the source CRM.
Signing in without a SQL database at all (a MongoDB-only session) stays quiet in all three places — that is not connected, not broken. MongoDB (local) sessions are not covered by the Disable Login check at all: they sign in with your registered client.techiecrm.com account (see Choosing the database type at login), and the source CRM's user table is not read in that mode. Disable Login governs Source CRM (SQL) sign-ins.
The four kinds of login, and what each one can reach
"Administrator" means different things depending on whose workspace is being talked about. There are four kinds of login on the platform, and it is worth knowing which one you are dealing with — especially the last two, which belong to TechieCRM rather than to your company.
| Login | Who has it | What it can reach |
|---|---|---|
| Workspace administrator | Your own company's administrator — the Admin role inside your workspace | Everything in your workspace: its users, security groups, teams, preferences, user-defined fields, email identity and plan. Nothing in anybody else's workspace, ever. This is almost certainly what you are. |
| TechieCRM staff | Somebody who works for TechieCRM | TechieCRM's own workspace, exactly the way you administer yours. Being a TechieCRM employee grants nothing about your workspace on its own. |
| Support administrator | A TechieCRM person who may be assigned specific customer workspaces, one at a time, by TechieCRM's own root administrator | Nothing by itself. It only makes it possible to be assigned a workspace. |
| Root administrator | TechieCRM's top account | Every workspace. This cannot be taken away — it is the account that has to be able to fix the platform when something has gone wrong with it. |
Two things about that table are deliberate and are worth stating plainly rather than leaving you to infer them.
Being a TechieCRM employee is now a separate fact from being able to reach your data. It used to be one and the same: any TechieCRM login with the Admin role could open any workspace. Those are now two different things that have to be granted separately, which is what makes it possible to employ a TechieCRM administrator who administers only TechieCRM's own workspace.
Today, a TechieCRM administrator can still open your workspace without asking you first. That is being replaced — the plan is that a support administrator must request access and somebody in your workspace must approve it, per session, with a stated reason and a log you can read. While a TechieCRM person is inside your workspace you already see a "support view" badge at the top of the page, so it is never invisible. The request-and-approve step, the log and the ability to end a session yourself are described in their own chapter when they land; this note is here so that nobody discovers the current position from the badge rather than from the manual.
Access rights enforced today
- User management: enabling/disabling logins, editing another user's details and changing security group membership all need the user-management right — see the table above.
- Note rights: users without the source CRM's note-modify right see notes read-only (MASTER always can).
- Full / Read access on notes, column setups, dashboards, KB owner: Public, Private, or a specific user/group — read live from the database.
- Shared dashboards can't be edited in place (save-as-copy).
- Cloud features are gated by the plan (A2).
Security Groups on the web portal — what unticking Read does
On the web portal (Workspace Admin ▸ Security Groups ▸ Access Rights) the Read column is enforced. Unticking Read for a module and pressing Save Rights:
- Closes the module for every member of that group, immediately — on their very next click, with no sign-out needed. Every way in closes together: the module's own page, its record windows, the panels it fills inside another module's page, and the app's data interface. There is no address that gets around it.
- Members see a page saying they don't have access to that module, naming it, and telling them to ask their workspace administrator. It is not an error, and nothing else in their workspace changes.
- The module also disappears from their sidebar, so nobody is invited to click something that will refuse them.
Three rules worth knowing before you tick anything:
- Deny wins across groups. If someone is in two groups and one of them has Read unticked for a module, they are denied — the other group allowing it does not override the deny.
- A group whose rights have never been saved allows everything. That is why an untouched group opens with every Read box already ticked: the screen is showing you what is true, not proposing a change.
- Only Read is enforced today. Insert, Modify, Delete, Export and Print are recorded against the group but do not yet restrict anything. The page says so above the table.
- A deny follows the records, not just the page. Pages that summarise other modules honour the same deny. In Reports, a report built from a module the member cannot read is simply not listed on the Reports page, and its address answers the same "you don't have access" message — so denying Service also removes Open Service Cases, denying Sales removes Sales Pipeline and Sales Won/Lost, and so on. Activity by User draws on Notes, To-Do List and Calendar together: denying one of the three removes that column and keeps the report; denying all three removes the report. My Work Day behaves the same way — a section whose module is denied is switched off rather than shown empty. Reports the member can read are unaffected.
Administrators are never locked out, by design: a workspace administrator can always open Security Groups and tick the box back on, and access returns immediately. That is also how you undo a mistake — nothing about it is permanent.
(This is the web portal's own security groups. The desktop's access-rights matrix is read from the source CRM and is still shown read-only — see "Not yet available" below.)
Modules in beta review, and the beta tester role
Some modules are finished enough to use and are still being reviewed before TechieCRM releases them. Those modules are open only to people who hold the beta tester role.
Open to everybody today: Clients (including the Related and Interactions panels on a client's page), Sales, Service, Dashboard, Library, Knowledge Base, Email, Calendar, Marketing, Agenda (My Work Day), Personal, Messages, Projects and Reports. Nothing about those changes.
(Calendar, Marketing, Agenda, Personal, Messages and Projects were released on 1 September 2026, and Reports on 3 September 2026. If you were using them as a beta tester, nothing about them changes for you either — the "In Beta Testing" ribbon simply stops appearing.)
In beta review: Inventory, Work Orders, Partners, To-Do List, Quotas, Financials, Agreements, Compliance & SLA, HR & Payroll, Order Desk, Notes and Documents.
The two add-ons are also in beta review: TechieCRM Connect (remote support) and the AI add-on (the cloud side of the AI features). See "The add-ons" below — they behave slightly differently because they are not ordinary pages.
Opening one of those without the role gives you a page saying the module is in beta testing and that you need to be a beta tester. It is not an error, and it is not a permission your own administrator withheld. Your workspace administrator cannot grant this one. Whether a module has finished review is a fact about TechieCRM's release programme rather than about your company, so only TechieCRM's root administrator can add somebody to the beta programme — ask TechieCRM support if you would like to help review a module.
Two things follow, and both are worth knowing:
- It is off for everybody by default. Nobody acquires it by being senior, by being an administrator, or by working for TechieCRM.
- A beta tester sees a diagonal "In Beta Testing" ribbon in the corner of every beta module's page, so it is never ambiguous which parts of the product are still under review. The same ribbon marks those modules on the public website. It disappears by itself when the module is released — there is nothing to switch off afterwards.
This is a different refusal from a security-group deny above. If the page says your administrator switched a module off, talk to your own administrator; if it says the module is in beta testing, talk to TechieCRM.
Desktop and mobile read the same role. When you sign in to the desktop app or a phone, the cloud tells that app whether you are a beta tester, so one change by TechieCRM applies everywhere you work without reinstalling anything.
The add-ons — Connect and AI
Both add-ons are in beta review, and both are refused in two places, because both are used from two directions: from the web portal in your browser, and from the desktop app or your phone with your licence key.
- TechieCRM Connect. Starting a support session — generating a support key, or checking whether the customer has arrived — needs the beta tester role, whether you do it from the portal or from the desktop's Connect panel. In the desktop you will see the request refused with a message naming the beta programme, which is not the same as the "Remote support is not enabled for this workspace" message (that one means the paid add-on has not been switched on, and is fixed by buying it; this one is not). Your client is never affected. A customer joining a session you started — typing your support key at connect.techiecrm.com, or clicking your link — is not asked about beta testing and never sees any of this. They are not a TechieCRM user and the gate does not apply to them.
- The AI add-on. The cloud side is what is in review: the cloud meeting summariser, and the service that lets a phone in the field find and use the AI agent running on your own computer. AI that runs entirely on your own hardware is not affected — TechieCRM's rule that AI functions run on a local model at no extra charge is unchanged, and Meeting Notes still records, transcribes and summarises on your own machine. Because these are machine-to-machine connections rather than pages, a refused request comes back as a short message to the app instead of a web page — there is no page to show, and no "In Beta Testing" ribbon on something that is not a screen.
For both add-ons the beta programme is attached to your licence, not only to your web login: TechieCRM can put a whole licence into the programme (so everyone working under it is in), or your workspace can be a TechieCRM partner, or the particular computer you signed in on can be recognised as yours after a real sign-in. Ask TechieCRM support which of those you want.
The Administrator window
The menu and the System Preferences pages (Clients, Key Fields, System Options, Locations/Resources, Mandatory Fields, Service, Sales, Diagnostic, Marketing, Automated Services, Dashboards, System Fields) are laid out to mirror the source CRM's Administrator; the working pages are Manage Users (edit a user's details, enable/disable the login, change a password, the access-rights matrix), Security Groups and Teams (group membership), Multi-User Licensing and the imports (A8). Everything else on the System Preferences side is still a placeholder — use the source CRM's Administrator for those.
Not yet available
Creating users (the SQL Server login and the account/rights defaults are created by the source CRM's Administrator; TechieCRM then shows and edits the user), editing access rights (shown read-only), creating security groups, user preferences, Windows authentication, database verification/repair, holiday editor (HR & Payroll has its own holidays for payroll — Chapter 22), and Change Password… on the Clients-list user menu (use the one in your own name menu, top right).
(Blocking a disabled login at the sign-in screen used to be listed here. It is built as of September 2026 — see Disabling a user login. It applies to Source CRM (SQL) sign-ins; a MongoDB (local) session is governed by your TechieCRM account instead.)
Choosing the database type at login
The Source CRM selector at the top of the Open Database Server dialog (reached from the login dialog's … browse button) picks the session's database: Source CRM (SQL) (the normal choice — everything you do is written to the source database and automatically synced to the local Mongo database and, when a cloud account is connected, to the cloud) or MongoDB (local) (preview). MongoDB mode warns you before continuing: records are then created and updated ONLY in the Mongo database and are not synced back to the source SQL database. Modules that still read the source CRM directly show no data in a MongoDB session.
MongoDB mode signs in with your registered TechieCRM account (client.techiecrm.com email + password), not a database password. The sign-in is verified against the TechieCRM cloud; once verified on a computer it also works offline on that computer. Your session then acts as the CRM user whose record carries that email (if none matches yet, the session falls back to the last SQL login and says so — account linking arrives with the first-run setup wizard). The … browse button in MongoDB mode lists the local Mongo server's databases, with TechieCRM databases marked, so you can pick the one to open.
Who the app thinks you are (record ownership)
Everything you create in the source CRM is stamped with a user login — the name that appears as the owner or creator of a client, note, appointment or message, and the name other people see when they ask "who wrote this?". The same login is what the emails and text messages you send are filed under.
TechieCRM works that login out in this order, and it always uses the first answer it can prove:
| # | Where the answer comes from | Trusted? |
|---|---|---|
| 1 | The login you signed in to the source CRM with this session | Yes — proven |
| 2 | A confirmed link between your TechieCRM account and a source-CRM user | Yes — you confirmed it |
| 3 | The last login used on this computer, remembered from a previous session | No — a best guess |
| 4 | Nothing is known | — |
Step 2 (linking your TechieCRM account to a source-CRM user, so the web portal and the mobile apps know which records are yours) is being built; today only steps 1, 3 and 4 can happen.
If nothing is known, TechieCRM has always fallen back to the login name
MASTER when it files an outbound email or text message. That has not changed —
changing it would re-file existing messages under a different name — but it is
no longer silent: a warning is written to the log every time it happens,
naming the reason. If you find messages filed under MASTER that should be
yours, that warning is the evidence, and the fix is to sign in to the source CRM
with your own login rather than opening the app without a database.
Support can read those warnings in logs/app.log, or turn on
Settings ▸ Diagnostics for more detail. No password is ever written to a
log file — the database password you sign in with is deliberately excluded
from every message the app records, including error messages.
In a MongoDB (local) session there is no source-CRM sign-in at all, so step 1 cannot apply: the session acts as the CRM user matched to your TechieCRM account email, and if there is no match it says so rather than pretending (see Choosing the database type at login, above).