The cloud connection: license, sync, backups, updates
TechieCRM Desktop talks to the TechieCRM cloud (techiecrm.com) for licensing, data sync, backups, app updates and messaging. The desktop only ever holds its license key; provider secrets stay in the cloud.
In this chapter - Trial, activation, check-in - Signing in with your TechieCRM account - The Cloud Connection dialog - The Database report (local vs cloud vs the source database) - Sync (offline-first) - Backups - Updates - Which modules your plan includes
Trial, activation, check-in
First launch starts a 7-day trial for this computer. The easiest way to connect a purchased
plan is Sign in with your TechieCRM account… (below); Enter a license key… remains as the
manual path. Two kinds of key exist and both begin TCRM-; the activation dialog tells them apart
by their shape, not their prefix:
- Cloud keys (
TCRM-…/TCRM-TRIAL-…, one continuous code) activate through the cloud and need an internet connection to activate. - Offline (signed) keys (
TCRM-XXXXX-XXXXX-….XXXXX-XXXXX-…, two halves joined by a.) are verified on your computer and do not need an internet connection to activate. See "Offline licenses" below.
If a signed key is mistyped or pasted incompletely, the dialog says so explicitly ("did not verify" / "length is wrong") rather than reporting a generic cloud error; check the key for typos.
The desktop checks in every 15 minutes in the background (license status, available update, what your plan includes, unread notifications). Offline, a cloud key or trial runs on the last check-in for a few days; an offline key runs for as long as its cached entitlement lasts (below).
Offline licenses
An offline key holds its own signed statement of what it grants (tier, expiry date and update entitlement), so the computer can prove the license is genuine with no server at all.
Every license has an expiry date, including Full. There is no perpetual license. A Full license works until the end of its expiry date and stops the day after, exactly like a Trial, Alpha or Beta license; renewing means activating the new key you are sent. (Full licenses have no check-in window, only the date.) A key that carries no expiry date at all is not valid: the Activation dialog refuses it with "This license key has no expiry date. Every TechieCRM license carries one, so this key cannot be used. Please contact TechieCRM for a replacement key." If such a key was already installed on the computer, TechieCRM shows the same message at start-up and opens the Activation dialog (instead of quietly starting a trial) so you can paste a replacement key. The License Information… window likewise never says "never expires".
Cloud licenses follow your subscription. A license that checks in with the cloud (your workspace's license) takes its expiry date from the cloud: when your workspace's subscription renews and the renewal is paid, the new date reaches this computer at the next check-in, with no new key to activate. An offline key keeps the date signed into it; when it is renewed, activate the new key you are sent.
- Activating without internet. Paste the key and click Activate. If the license server cannot be reached, activation completes from the key's signature and the dialog says "License activated offline… It will register with the server automatically the next time it is online." The computer is fully licensed from that moment. If the server can be reached but refuses the key (an unknown or inactive key), activation fails and is never completed offline; a refusal is an answer, not an outage.
- Registering later. The next time the computer is online, its background check-in registers it with the license server. There is no limit on how many computers a TechieCRM ID may be used on. Should the server refuse the key itself (revoked or inactive), this computer goes read-only and the reason is shown; contact support.
- How long it works offline. As long as the license's cached entitlement lasts: every key ends on its own expiry date, Full included. Trial, Alpha and Beta keys are also bound by the check-in window the license server sets at activation (currently 7 days, plus 3 days' grace): stay offline past that and the session becomes read-only until the next successful check-in renews it. The window length is a server setting, never something the desktop decides for itself.
- Your computer's clock. The license remembers the latest time it has seen (from the server when online, from your clock otherwise). Setting the clock back does not extend a license; if the desktop notices the clock is behind that mark it logs CLOCK ROLLBACK DETECTED. A clock that was accidentally set far ahead recovers automatically at the next successful check-in.
- One hardware change is tolerated. Replacing a disk or network adapter does not invalidate the
cached license (3-of-4 fingerprint tolerance). A second unrelated change does; re-activate with
your key (a plain-text copy is kept beside the license file as
license_key.txt). - If the license file is damaged or edited, the desktop treats the computer as unlicensed (read-only) rather than guessing; the startup log says why. Activate again with your key.
No active license? Your data stays yours. TechieCRM never blocks you from opening the app or reading your records. With no active license (trial over, never purchased, or lapsed) the session simply becomes read-only: a notice explains it, you can open and read every record, but creating, updating and deleting are disabled until a license is activated. Cloud features (sync, texts, backups to the cloud) also pause. Activating at any time (including mid-session) restores full function immediately. The same rule applies on the web portal.
License Validation, revocation and device release
What the background check actually is. The 15-minute check-in is License Validation. It is not an expiry check; your license carries its own expiry date, and the desktop knows it without asking anyone. License Validation asks one question: has this license, or this computer's place on it, been revoked? If the server cannot be reached, the desktop consults a signed revocation list instead (below). If neither says revoked, the license keeps working until its own expiry date, however long you stay offline. (This supersedes the "check-in window plus 3 days' grace" wording under Offline licenses above, which described the earlier behaviour: an offline computer is no longer locked for missing a check-in.)
The signed revocation list. An application update or security patch can carry a list of revoked licenses; installing the update applies whatever list it carries, and the next successful validation brings a newer one. (Updates published so far carry no list; the list is issued by the license server, which does not publish one yet; until it does, revocation comes from License Validation and from the list already stored on the computer.) The list is signed with the same key as the licenses themselves, and the desktop refuses any list it cannot verify; an unverifiable list is simply ignored, never treated as "revoke everything". You are never shown the list; it only affects a computer that is no longer entitled to run the software.
What a revocation does. A revoked computer becomes read-only immediately, and stays revoked after a restart or offline. The notice names the user whose license was revoked. Two kinds:
- The whole license revoked (by TechieCRM, for example a chargeback): read-only, nothing else happens to your data.
- This computer removed from the license by the license owner (a user was un-assigned on client.techiecrm.com): read-only, and (only if the owner asked for it) a device release:
- every change made on this computer is uploaded to the cloud;
- the upload is verified: the desktop independently checks that every record it holds was received;
- only then the local database connected to that license is removed from this computer;
- you are told: the license connected to \<user> has been revoked from this device, and \<user>'s data has been removed.
The license owner's own data is never removed. A device release applies only to a user the owner gave access to and later removed. The desktop establishes who holds the license on this computer from evidence it can verify itself (the owner's identity signed into the license key, or a signed revocation entry naming the owner and the removed user, checked against who is signed in here), never from a server flag alone, and if it cannot positively tell, it leaves the data alone. (Transferring a license to someone else is a separate process, not part of this.)
If the upload does not complete and verify, nothing is removed; the desktop says so and tries again the next time it connects. A computer that also holds a different license with its own database (for example your personal one) keeps that database untouched: only the database explicitly bound to the revoked license is ever removed, and if no such binding is recorded, nothing is.
When the desktop cannot be certain which database server holds that data, it does not
guess. Two situations cause this: the license's database is recorded as localhost on the
port of TechieCRM's own password-protected database server, or it lives on a custom database
server (a MONGO_URL setting) that asks for a password TechieCRM does not keep with the
license. Each time, nothing is opened or removed, and the desktop tries again the next time it
connects. After 3 attempts for the same removal, the notice (and Help ▸ License
Information ▸ Local data) changes to say that TechieCRM could not safely finish, gives the
reason, confirms that no data has been removed, and asks you to contact TechieCRM
support and quote the message. Support is a web page, not an e-mail address:
www.techiecrm.com/support/ explains how to get help
and links to the contact form. The count is kept on this computer, so it survives a restart;
it starts again if the owner issues a new removal, and it is cleared once a removal completes.
Reaching 3 attempts never removes anything; it only changes what you are told.
Which database is "bound" to a license. The binding is recorded when the license and the database are first put together, from one of exactly three places: an activation on the Configuration window's Licence page (a key, or Sign in with your TechieCRM ID; it replaced the first-run setup wizard's Your local database page in October 2026, Administrator Guide A14); activating a license key anywhere else at any later time (so a computer licensed on day two gets a binding as well, which is what makes a device release possible on it at all); and the license server itself, which names the workspace database on every successful check-in. Nothing else creates one; in particular, "the database that happens to be open" never does. Without TechieCRM's database engine on the computer nothing is bound. If the license is already bound to a different database, the Licence page and a later activation keep the existing binding rather than moving it; only the license server can point a license at a different database. A database already bound to another license on the same computer is never bound to a second one. Settings ▸ General ▸ License Information… shows the binding currently recorded on this computer.
A computer that was licensed before this version has no binding recorded (nothing was creating one at the time). Its data is simply never removed; the release refuses and says so. Re-activating the same key from Enter a license key… records the binding.
Seats. Removing a user from a multi-user license does not free their seat straight away. The seat is pending release until every one of that user's computers has come online, been revoked and confirmed back. Settings ▸ General ▸ License Information… shows the seat count, who holds which seat, and each registered device's status.
Signing in with your TechieCRM account
Tools ▸ Cloud ▸ Cloud Connection ▸ Sign in with your TechieCRM account…: enter the email and password you created on techiecrm.com. TechieCRM fetches the license(s) on your account, shows each one with its plan and company name, and Activate on this computer connects this machine, with no key to copy. Notes: - Your password is never stored on this computer; only the fetched license key is kept. - A license can be activated on as many computers as you need; there is no computer limit. - After several failed sign-ins (five within fifteen minutes) the account locks until support reviews it; the lock raises a support ticket automatically. Repeated failures from one network address are also blocked. - Signing in also fills in your portal email for notifications. - Signing in on the web portal counts as a place: once TechieCRM switches it on for your workspace, your ID can be used in one place at a time (see Signing in from more than one place).
Your phone and My Devices
Your ID works on any number of computers and in any browser. A phone is personal: one phone is registered to your ID the first time you sign in to the TechieCRM app on it, and you receive an email saying so. Open your name in the web portal and choose My Devices to see every computer, phone and tablet that has signed in with your ID (October 2026: computers are listed too, with whether you are still signed in on each). A device shows Online while it keeps checking in with TechieCRM and Offline once it has not checked in for 35 minutes (twice its usual 15-minute check-in, plus a short grace), so a computer that is simply between check-ins never shows Offline. To change phones, press Remove next to the old phone (it erases its TechieCRM data the next time it connects). For a shared office computer you walked away from, press Sign out instead: it keeps its data, stays allowed for your synced mail accounts (no new approval when you come back) and asks for your password the next time you use it there (see Your sign-in on this computer in Users, security and login). If someone else signs in to the app on a phone registered to you, the phone moves to them and you both receive an email: they are told it is now registered to them, and you are told it is no longer registered to you. If you did not pass the phone on, tell your administrator and change your password, because someone else may have your phone. Tablets are shared and are not counted as personal devices. A phone nobody has signed in on stops syncing after 30 days until someone signs in.
Computers set up for your workspace (administrators, October 2026). Each computer the TechieCRM
installer sets up is registered to your workspace only, and stays so until TechieCRM is uninstalled
on it with Reset settings ticked. If you are an administrator of your workspace, My Devices shows a
second list, Computers set up for
What the cloud keeps about your mail accounts
Once mail account sync is switched on for your workspace (October 2026), the cloud carries your mail accounts to your own devices. It keeps your addresses and the plain settings it needs (display name, account type, which is your default), and a sealed copy of the rest (servers, user name, password, other addresses, trusted certificates) that only your allowed devices can open. The cloud never holds the key that opens it, so TechieCRM cannot read a mail password, and no administrator or colleague can either. Mail itself is never kept in the cloud. See Communications, Your mail accounts on all your devices.
The Cloud Connection dialog
Tools ▸ Cloud ▸ Cloud Connection (or Tools ▸ Cloud ▸ Sync Now): license and status, cloud subscription, features (Text, desktop email accounts, web email identity, cloud sync, cloud backup, notifications, modules not in your plan), sync state and last result, the local mirror's record counts, last check-in, server. Buttons: Check in now, Sync now, Initial full sync…, Backups…, Database report…, Sign in with your TechieCRM account…, Enter a license key…, your portal sign-in email (used for notifications), and Keep this computer in sync with the cloud. Links open the portal pages for downloads, SMS number, email identity, email templates, conversations. The window opens at once, even on a slow network; the release programme line fills in a moment later (see The release programme below). The Cloud Connection… button in Settings ▸ General ▸ License Information… opens the same window (from the October 2026 update; before it, that button only reported that the window could not open).
The Database report
Cloud Connection ▸ Database report… answers "what is my data, where is it, and why do the numbers differ from my source CRM?": everything counted live when you open it (nothing is estimated; a section that cannot be computed says why instead of showing numbers):
- Your database: this computer vs the cloud. Each kind of record (clients, notes, meetings, …) with the record count and size on this computer next to the count and size in your cloud database, the same figures TechieCRM uses for storage billing. When this computer and the cloud match, the two TOTAL columns agree.
- What syncs. How many kinds of records sync, whether sync is on, the time everything up to which is already on the cloud, and exactly how many records are waiting to upload on the next sync (or "Nothing is waiting to upload").
- Data health: TechieCRM vs your source database. A read-only, live comparison against the source-CRM database this computer is connected to: rows in the source database, actual records (with its duplicate copies collapsed), and in TechieCRM, each with a plain-language explanation. The key story: the source CRM stores separate copies of the same record: a meeting (it calls them appointments) is filed once for every person linked to it (four attendees = stored four times), and a saved email is filed once for every client entry it was saved to (and again per user who saved it), so its raw row count is inflated. TechieCRM stores each meeting and each unique email once, with the full list of people and places it connects to. An email only counts as a duplicate when its entire content matches (subject, date and time, sender, recipients, body and attachments) and every collapsed copy keeps a reference back to its original source record, so the de-duplication is fully reversible. A smaller database in TechieCRM does not mean missing data: every meeting, email, note and contact is still there, stored once. Nothing in the source database is ever modified by this report. If the source CRM is still in use, remaining differences simply reflect records added or removed there since your last import.
Sync
When your license is linked to a cloud subscription (a tenant database), the desktop keeps a local mirror (MongoDB on this computer) in sync with your cloud database: pull, then push, every check-in. Conflicts resolve last-write-wins; deletes carry over. Inbound texts/emails reach the desktop this way. Until the subscription is active, the dialog says "not granted" and nothing is sent.
How "last write" is decided, and what the two timestamps on a record mean. Every synced record shows a Modified time (the clock of whichever device made the edit) and carries a second, invisible stamp the cloud writes when the change reaches it. The cloud's stamp is what orders the sync: it decides which records a device still needs, and when two devices change the same record the change that reached the cloud last is kept. The device clock never decides that, so a computer or phone whose clock is wrong can neither lose its own changes nor win every conflict. This applies to every kind of record, invoices, bills and payments included: when the same one is edited on two devices before they sync, the later arrival replaces the earlier and nothing flags that a value was overwritten. If you rely on a figure that was edited from two places, check it after the sync.
Desktop saves reach this computer's copy straight away (October 2026 update). When you save a note, a to-do, a meeting, a document, a client entry or contact, a sale, a ticket or a user-defined field on the desktop, TechieCRM writes it to the office CRM and, in the same save, copies it into this computer's own TechieCRM database (the local copy the cloud sync sends from). The next check-in then carries it to the web portal and the phones. Before this update an edited note, a rescheduled meeting or a completed to-do stayed on the desktop and never reached the web or the phones. Deleting a note, to-do, meeting or document removes the local copy too, and the delete travels with the next check-in. Assigning a ticket and scheduling a project plan are copied the same way once their whole change has been saved.
If the copy cannot be made at that moment (TechieCRM's own database is not running, or the office database could not be read back), the save still stands in the office CRM; nothing needs re-entering. TechieCRM keeps a note of what is waiting in its own database, so it is not lost if you close the app, and tries again at each check-in. While something is waiting, the red Issues bell shows one row for this computer, A saved change has not been copied for the cloud yet, with the sentence "It is saved in the office CRM. TechieCRM could not copy it for the cloud just now and will try again at the next sync." The row counts how many times it happened and closes by itself once everything waiting has been copied. (If TechieCRM's own database is not running at all, the waiting list is kept until it is running again, and is lost only if the app is closed before then; the next full refresh then carries the change.)
The same record changed in the office CRM and on the web or a phone (October 2026 update). When TechieCRM copies a client entry, contact, sale, ticket, note, document, to-do, meeting or expense from the office CRM into its own database, it no longer replaces the whole record. It compares each field with what both sides last agreed on, and judges field by field:
- a field changed only in the office CRM is copied across;
- a field changed only on the web or a phone is kept, and waits for the office CRM (the record is marked as waiting until that write-back is built; nothing is lost meanwhile);
- when the same field changed on both sides, the newer change is kept and the other value is set aside for the record's history (History notes are a coming update; until then the value is kept in TechieCRM's own database);
- fields TechieCRM does not copy are never touched.
The first time a record is compared this way there is no record of which side changed a field that differs, so each such field is settled by the newer change time (the office CRM wins a tie) and listed for administrators. The red Issues bell then shows one row, Differences were settled when the office database and TechieCRM's copy were first compared, with how many field values it covered; the list of every record, field and both values is kept in TechieCRM's own database. Nothing is written to any record's history for these first-time differences.
Changes made in the office CRM program reach the web and phones when you look at them
(October 2026 update). Whenever the desktop reads a list or opens a record from the office
database (a client entry, a sale, a ticket, a document, the Activities list, the To-Do List or
the Calendar), it compares each row it read with the copy it last sent to TechieCRM's own
database. A row that changed in the office CRM program since then, including notes, to-dos,
meetings and documents, which the office CRM keeps without a change date, is copied into
TechieCRM's own database before the view shows, field by field, with the rules above. So the web
portal and the phones receive an office change at the next check-in after anyone on the desktop
has looked at it, instead of waiting for a timer. Nothing changes on the desktop itself: the list
shows what the office database holds, and the check never delays or blocks a read on an error.
Rows nobody looks at are covered by a nightly compare, which walks every office record once a
night (from 1 AM on the desktop computer's clock) in small batches, resumes where it left off if
the computer was closed, and is run by one computer at a time (the same shared lease the office
refresh uses). An administrator can see its progress in TechieCRM's own database
(_sync_state, nightly_compare:<table>); it has no screen of its own yet.
Each save made in TechieCRM also leaves a small record stamp in the office database
(TCRM_Record_Stamp: the table, the row, who saved, when in universal time, which fields). The
stamp lets TechieCRM tell its own saves from edits made in the office CRM program and decide a
same-field conflict by real times. The table is created by Configuration ▸ Database ▸ Prepare
like TechieCRM's other side tables; until it exists on a database, saves work exactly as before
and simply carry no stamp.
Times from the office database (October 2026 update). The office CRM keeps many of its times (when a ticket was created or resolved, when a record was last changed, when a note was written) in the office's own local time. TechieCRM now converts each of them exactly once, with the office database's time zone (detected from the office server's clock; Chapter A14, "The Database page"), when it copies the record into its own database. So the times you see on the web and on phones are the office CRM's times shown in your own time zone, and a change made in the office CRM is picked up by the next sync whatever the hour (before this, an office edit could wait until the next full refresh, and a note written on the 24th could show on the evening of the 23rd west of Greenwich). Each converted record carries a small marker, so a record copied before this change is told apart from one copied after it; the one-time conversion of the records already copied is a separate step that an administrator approves on the Database page (Chapter A14). If TechieCRM cannot work out the office database's time zone, copying of the records that carry office times pauses and the Database page says why; records whose times are already universal (meetings, to-dos) keep copying.
Private notes and sync. A note you mark Private in the web portal is yours: colleagues do not see it in a list, in a count, on a client's Interactions panel or on its own page. Only you, and your workspace administrator (who can read it but never change it), can open it.
What that means for your other devices, as things stand today: - On the web: you see your own private notes, everywhere you would see an ordinary one. - On your phone: once you have signed in to the app with your TechieCRM email and password, your own private notes sync down to it, and the Private mark comes with them, so you can turn it off from the phone. Private notes belonging to anyone else are never sent to your phone. A phone that has not signed in receives none at all. - On the desktop: private notes are not synced to the desktop app yet. This is deliberate and temporary: a desktop installation can be shared between several logins, and the desktop app cannot yet hide one person's private notes from another, so they are held back rather than shown to the wrong person. When the desktop can filter them, they will sync there too. Nothing is lost in the meantime; the note is safe in the cloud and on the web.
Saved logins and sync (Credential Storage Manager, October 2026). Logins you keep in the
Credential Storage Manager follow you to every computer where you sign in with your TechieCRM ID,
and nobody else. They travel and are stored encrypted: the cloud keeps only locked copies and
cannot open them, and it refuses any login that arrives unlocked. A computer receives a saved login
only when the person signed in on it owns it or it has been shared with them; a computer where
nobody has signed in with a TechieCRM ID receives none at all. An administrator who holds the
office recovery key receives only the title, type, sites and owner of the office's Business
logins, never a password or any other secret, and never a Personal login (chapter 31). When a login stops being shared with someone, their
computers stop receiving it and remove their copy at the next sync. If a different person signs in
on a computer, that computer fetches that person's saved logins in full at the next sync. In the
Database report they appear as seven record types whose names start with cred_; their cloud
count is only what the person signed in on this computer may receive, so it can be lower than the
count on this computer when several people share it. The manager's window itself arrives in a later
update.
Sales: competitors, partners, Lost to and completion reasons (October 2026). Each sale now carries its Competitors / Partners list (with each entry's name and the link's comment), its Lost to and its Completion Reason to the cloud, so the web portal, the local portal and the phones can show them. The office database stays the source: the desktop reads these values (it never changes the office database to send them) and sends what it finds. - When a change goes up. A sale saved in the Sale window is sent at the next check-in, including a save that changed only the Competitors / Partners tab. A change made in the source CRM itself goes up at the next check-in when it changes the sale; a competitor or partner added there without touching the sale waits until the sale is next changed or saved. - The first check-in after this update reads every sale once, so sales nobody has opened in years get their lists too. On a large database this check-in takes longer than usual, once. - The list of completion reasons (Won, Lost, Abandoned and Suspended reasons, with which status each is offered for) is sent at every check-in and straight after it is changed in Settings ▸ Sales. A reason removed from the office is kept in the cloud as no longer in use, so a sale that still names it keeps its label; it is never offered again. If the reasons cannot be read at a check-in, nothing about them changes in the cloud. The reason list starts going to the cloud as soon as your cloud is ready to receive it; until then it waits on this computer. - What a blank means. "Not synced yet" (on the web) means the sale has not been sent since this update. A Lost to or reason that names an entry or reason no longer in the office shows without a name rather than with a wrong one. - Changes made on the web or a phone wait for the office computer. When someone changes an office sale's competitors or partners on the web portal or the local portal, or closes it as Won, Lost or Suspended (with its Lost to and reason) there or on a phone, the cloud does not change the office database itself: it has no connection to it. The change is stored as a request, and the web shows the sale with a Waiting for the office badge (a removed entry is struck through with Removal waiting; a pending close reads "Won, waiting for the office"). At its next check-in whichever office program picks the requests up first (the desktop app signed in to the office database, or a local portal with its SQL Server set, chapter A13) takes them, oldest first, and writes them into the office database using the same safe writes as the Sale window. Each request is then marked and the badge goes away at the following check-in, so a change made on the web typically shows in the office within two check-ins (about 30 minutes at the default interval). The office computer must be running and signed in to the office database; while it is off, requests simply wait, and the badge says so ("Waiting: the office computer has not synced since time"). - Which program writes them. No setting decides it, and the Sync line in Setup ▸ Settings ▸ Local Database does not either: on a computer where the local portal syncs with the cloud, the desktop app still writes the requests the portal's sync brings into the shared database, and the portal sends the results up. The programs take turns through a 20-minute office-write lease on the TechieCRM database (separate from the one that runs the refresh and the monitors, so a portal writing office changes never stops the desktop app refreshing), and each request is taken by one program at a time, so a change is never written twice. A desktop app signed in without the office database does not take part. - Changes made on a phone to an office sale wait for the office computer too. A Won or Lost close made in the TechieCRM app is sent as the same kind of request, and the app shows Waiting for the office until it is written; if your TechieCRM ID is not linked to an office CRM login, the app says so and nothing is sent. - Who the change is recorded as. The request carries the requester's linked CRM login (the one their TechieCRM ID is linked to), and the office rows are written as that login, never as the office computer's own. A requester whose login does not hold the source CRM's Opportunities modify right has the request refused: "Your office CRM login is not allowed to change sales." - The office wins. Each part of a request is checked against what the office holds now. An entry already added, or already removed, is simply accepted. A comment, Lost to or reason is written only if the office value is still the one the requester saw; otherwise that part shows "Changed in the office since you opened it: now X" with the office's value, and the other parts are still written. For a Won/Lost close the status is the gate: if the sale's status changed in the office meanwhile, nothing in that request is written and the whole request shows the conflict. A reason removed from the office since fails that part ("That reason was removed in the office."). A sale deleted in the office fails the request ("This sale no longer exists in the office database."). - After every request, applied, in conflict or failed, the office computer re-reads that sale into the cloud at once, so the web and the phones show the office's own values rather than the requested ones. - Failed and conflict requests stay visible on the web with their reason and a Dismiss button (and Try again for a failure). A request that could not be applied because the office database was briefly unreachable is not failed: it is put back in the queue and tried at the next check-in. - The desktop's Cloud Connection check-in result records what the applier did on this computer ("ran: 2 done, 1 conflict, 0 failed, 0 released", or why it was skipped). - Changes made on phones reach the office computer (October 2026 update). On the same kind of workspace, a to-do, meeting or ticket added on a phone or tablet, and a change made there to one that came from the office database, go through the same queue. The phone saves the record in TechieCRM at once (every device sees it, marked Waiting for the office), and at its next check-in the office computer adds it to the office database with the desktop's own To-Do, Meeting and Ticket writers, recorded as the requester's linked CRM login. The office then re-reads the new row into the cloud under its own record id, and the phone's provisional copy is retired, so the record is never shown twice. A change to an office record is checked field by field, as sales are: a field changed in the office since the phone saw it keeps the office's value and the line says so; the rest is written. - Who may add what. A ticket needs the requester's login to hold the Customer Service insert right (modify, for a change); a to-do or meeting needs only a login the office knows. A refused request reads "Your office CRM login is not allowed to add tickets." (or "change"). A ticket whose status label is not in the office's own list is refused with that reason rather than saved with a guess. - Never written twice. The office computer keeps a small log of its own (one row per record it has added, in the office database) and writes it in the same transaction as the record, so a computer that loses power between adding the row and reporting it cannot add it again at the next check-in. - Times. A phone sends times in UTC. To-do and meeting times are stored in the office database the way the desktop stores them (UTC; a to-do with no time keeps its day), and a ticket's resolved date is stored in office local time, as the office CRM does. - Where it runs. The desktop app signed in to the office database writes these. A local portal applying sales requests on its own leaves to-do, meeting and ticket requests waiting for a desktop, and says so in its sync output. Until the release check for these writers has been run on a test database, the desktop app also leaves them waiting ("record requests wait") and writes sales only.
Interaction groups (October 2026). Groups of a client's interactions (the notes, documents, to-dos, meetings and other items you tie together in the Interactions panel, with the sales and tickets they are linked to) are kept in your office database. The desktop sends a copy of every group to the cloud, so the web portal and, later, the phones can show them. - The office database is the source. At every check-in the desktop reads all the groups from the office database and sends what it finds. If the cloud's copy of a group differs from the office, the office's version replaces it. A group you dissolve (or empty) in the office is removed from the cloud at the same check-in. A group brought back with Undo goes back up too. - Only the office changes groups. The web portal shows groups but does not change them, and the cloud refuses a change to a group sent from a phone or tablet: "Interaction groups are changed on the desktop." - What is sent is the group's name, which items are in it (by their record numbers, not their text) and which sales and tickets it is linked to, with who made each change and when. Everyone in your workspace can see the groups, the same as notes and documents; a private note in a group stays private, but the group shows that an item is there. - When it goes up. A change made on this computer goes up at the next check-in (about 15 minutes at the default interval). If the office database cannot be read at a check-in, nothing about groups changes in the cloud. The groups start going to the cloud as soon as your cloud is ready to receive them; until then they wait on this computer.
SLA clocks (October 2026). The SLA clock of every ticket, work order and maintenance plan (the trackers on the Compliance & SLA board, chapter 11) now goes to the cloud, so the web portal's SLA board and the Ticket SLA breached monitoring rule can see them. - What is sent for each clock: what it tracks, its policy and the policy's response and resolution hours and working day, when it started, its respond-by and resolve-by deadlines, first response and resolution, whether it is paused (by hand, or because the ticket is in a Waiting status, with that status's name), its status (on track, at risk, breached, met, paused or cancelled), when it was last checked, and its history (attached, at risk, breached, paused, resumed, notes). Everyone in your workspace can see them; a clock belongs to the ticket, not to a person. - Times. The office database keeps these times in the office's own time; the cloud keeps true UTC, so every device shows them in its own time zone. The office's time zone is sent with each clock, so the working day (for example 08:30 to 16:30) is read in the office's time. - When it goes up. At every check-in of the office computer that runs the refresh (the one signed in to the office database), and from a local portal with its SQL Server set. A clock that did not change is not sent again. The SLA check runs about every hour, so the cloud's "last checked" time is never more than about an hour and a check-in behind. - A clock removed from the office is kept in the cloud as no longer in use: the web board no longer lists it and the monitoring rule ignores it. If the clocks cannot be read at a check-in, nothing about them changes in the cloud. An office database where Compliance & SLA was never set up sends nothing. - Only the office changes clocks. The cloud refuses a change to a clock sent from a phone or tablet: "SLA clocks are worked out by the office computer." - A desktop app that is not connected to the cloud does not keep this copy, so on such a computer the Ticket SLA breached monitoring rule still finds no clocks.
If part of a sync was not stored. The Cloud Connection dialog's Sync line normally reads "last: pulled 12, pushed 7". If the cloud could not accept one kind of record, that line adds "⚠ NOT STORED by the cloud:" followed by what it refused. This means exactly what it says: those records are still safe on this computer, but they did not reach the cloud, so they are not on the web portal or your phone, and a colleague will not see them. Everything else in the same sync did go up. It is not something you can fix from here: it means this version of the desktop app is sending a kind of record your cloud does not yet know about, so report it to support with the name shown. Sync carries on normally for everything else in the meantime.
When the cloud asks for a full refresh
If a computer has been switched off, or off the internet, for a long time, the cloud may decide it can no longer safely bring that computer up to date one change at a time, and asks it to download a complete fresh copy instead. The desktop does this on its own; you do not have to do anything, and nothing is lost. The next sync simply takes longer than usual: minutes rather than seconds, depending on how much data your company has.
Why it happens: when a record is deleted, the cloud remembers the deletion for a while so every device gets the news, and then it stops remembering. A computer that was away for longer than that would never hear about the deletion, would still be holding the record, and would send it back, and the record would come back to life for everybody. Rather than let that happen, the cloud refuses the short-cut and asks for the full copy.
What you will see. Open Settings ▸ Database and look at Cloud (sync.techiecrm.com) ▸ Last sync. After a forced refresh it includes the cloud's own explanation, for example "This device has been offline too long to catch up safely…". Sync then carries on normally on the next check-in.
Not built yet: the explanation is not currently shown as an on-screen banner while the refresh is running, so a long full download still looks like an ordinary slow sync. Only the Settings ▸ Database line reports it afterwards.
If it keeps happening. A full refresh should happen once and then settle. If Last sync keeps reporting "Cloud sync is stopped…", the desktop has deliberately stopped trying rather than ask the same refused question over and over; that is a fault on the cloud side, and it needs support. The desktop will keep checking once per check-in in case the cloud recovers; it will not repair itself by being restarted.
Backups
Backups…: Back up now writes a snapshot of the local mirror to ~/.techiecrm/backups/ (the
last ten are kept) and uploads it to the cloud when your subscription allows (cloud backups are kept
90 days). A weekly snapshot runs automatically. Restore selected… re-imports a local snapshot
(records replace those with the same id, confirmed first).
Bringing a cloud backup back (September 2026 update). The In the cloud tab lists what has been uploaded, with its size and record count. Select one and choose Download selected… to copy it to this computer; it then appears on the On this computer tab, which is where restoring happens. So retrieval is now two steps (download, then restore) rather than a support request.
Three things the tab will tell you rather than letting you find out the hard way:
- A backup with no stored archive (the cloud has the listing entry but not the file) has its Download button greyed, and the note says how many are in that state. There is nothing to restore from; take a fresh backup.
- A backup taken before 11 September 2026 is missing 15 collections, because of a fault in how snapshots chose what to include. You are warned before the download and again after it. It will restore, but it will not bring back everything the list appears to show.
- An older cloud server that does not offer downloads yet says exactly that. It is not a problem with your backup.
Keep the local copies regardless: the cloud copy protects you against losing the computer, and the local copy is still what you restore from.
Restoring: keep your newer work, or go back exactly (September 2026 update)
Restore selected… now asks what should happen to work you have done since the backup was taken. Both answers are right for different situations, so TechieCRM asks rather than deciding:
| What it does | When it is the right choice | |
|---|---|---|
| Keep my newer work (recommended, and pre-selected) | Records from the backup are put back, but anything you have changed since is kept as it is now, and records you have added since are left alone. | Almost always. You lost some records, or you want something back from an old backup without undoing this month's work. Nothing you have done since the backup is lost. |
| Go back to exactly this backup | Everything the backup covers is cleared and rebuilt from it, so TechieCRM ends up exactly as it was when the backup was taken. | Only when the current data is wrong: a bad import, or a change you want undone completely. Anything created or changed since is permanently removed, and you are asked to confirm a second time. |
When the restore finishes, the status line says how many records were put back and (after a Keep my newer work restore) how many newer records were kept. That second number is your confirmation that recent work survived.
Filed documents and e-mail bodies are kept in both cases. A backup stores your records, not the attached files, so a restore never replaces a document you can already open with an empty one. That is true even of Go back to exactly this backup: it can restore the record, but it never held the file and cannot put one back.
What a snapshot contains. Everything in the local mirror: clients, notes, sales, tickets, appointments, tasks, documents, campaigns, the library, quotas, expenses, inventory, employees, maintenance agreements, invoices and payments, your saved column layouts and Key Field setups, and your preferences. Two things are deliberately left out, and the snapshot names anything it left out, so you can always see what is in the file you are holding:
- the assisted-AI work queue (a list of jobs waiting to run, not information you entered);
- TechieCRM's own copy of your Inbox and Sent mail kept in the local database (record types
whose names start with
mailbox_). Your mailbox never leaves your computer: unfiled mail stays there and on your mail server, never in a backup and never in the cloud. Email you file on a client becomes a document and is backed up like any other record. In that copy the subjects, senders and recipients are stored readable, so the list can sort and search them; the message text is encrypted with your own mailbox key, kept on this computer. Anyone who can open the local database directly (an administrator tool, a copied data folder) can read the subjects and senders, but not the messages.
Emails waiting in Send Later are backed up, attachments included, so restoring a backup brings back emails that were still waiting to be sent.
Saved logins from the Credential Storage Manager (record types whose names start with
cred_) are backed up too. They are stored locked, so a backup file holds nothing anyone can
read, and restoring it brings the logins back for the people who could already open them.
Before September 2026 this was not true, and it is worth knowing if you are relying on an older backup file: snapshots taken by earlier versions covered a fixed list of record types drawn up when the feature was written, and anything added to TechieCRM afterwards (the library, quotas, expenses, inventory, employees, maintenance agreements, your column and Key Field layouts and your preferences) was left out without saying so. A snapshot file dated before this change may not contain everything you expect. If one is your only copy of something, take a fresh backup now, while the original data is still in the app.
Updates
Check-in tells the desktop when a newer version exists: security / mandatory updates must be installed to continue (Download → Quit); bug-fix updates are recommended; feature updates are offered once. Downloads come from the portal's Download page.
Cloud (Aug 2026): while a platform's installer is still waiting on its code-signing certificate, the Download page says so: testing is wrapping up and the certificate for that platform hasn't landed yet, both at once. Until it does, the operating system or antivirus may warn that the installer is from an unidentified/unrecognized publisher; installing is safe but at your discretion until the certificate is added, at which point the warning disappears on its own and every registered individual and company gets an email.
Which plans include the desktop app
The Entrepreneur plan covers the web portal and the mobile apps; it does not include the installed Windows or macOS application. The Download link stays exactly where it is on every plan: click it and, if your plan doesn't include the desktop app, the page says so and names the upgrade (Team or higher) instead of the link quietly disappearing. A workspace administrator can make that change under Plan & Billing, and the download works from that moment. Anyone who is not signed in (a visitor evaluating TechieCRM) can still download and try the desktop app.
What your plan includes
Modules not in your plan are dimmed on the icon bar with a tooltip. Trials include Clients, Contacts, Notes, Interactions, Calendar, To-Do, Email, Messages and Personal; subscriptions unlock the rest. Text messaging is an add-on; email from your own account is always available. Web forms (Tools ▸ Internet ▸ Web Form: an enquiry form on your own website whose entries become Prospects) need a TechieCRM cloud subscription, because the forms are built and received on the TechieCRM website. Every paid cloud plan includes them, starting as a beta, with a limit on how many forms can be switched on at once: Entrepreneur 2, Team 5, Business 20, Corporate 50. Each form has an Include submitter IP address box under What happens to an entry (off by default): when ticked, the IP address each entry was sent from is kept with the entry for 1 year and shown in the entry email and on the entry; the visitor never sees it. Without a cloud subscription the desktop's Web Form button is greyed; rest the pointer on it to see why. The button follows your licence: after a check-in that adds or ends the subscription it changes by itself. Plans are priced per user per month on an annual plan and billed for the full year in advance. They renew automatically each year, and your workspace administrators are emailed 30 days and 7 days before each renewal (see A2, Plan & Billing).
The initial full sync (new companies)
The first time a company connects its local database to the cloud, use Initial full sync… (TechieCRM also offers it automatically right after you activate a license when the cloud tenant is still empty). A progress window opens and stays on top of the work; you can move it aside or press "Hide (keep syncing)" and carry on using TechieCRM while it runs.
The window shows, live: - an overall bar: records synced so far, the percentage done and the percentage remaining; - every part (Clients, Notes, Documents, Meetings, Sales, Service tickets, …) with its own record count and percentage, marked Waiting, 🔄 Syncing… or ✅ Synced; - a status line naming what is being synced right now, and a final summary (records added/updated).
Stop sync halts cleanly after the current batch; nothing is lost; running the sync again picks up exactly where it stopped. Re-running a completed initial sync is also safe: records that are already in the cloud simply become updates, never duplicates.
The Personal journal is left out of the initial full sync, because each person's journal syncs only to them: it travels with the everyday sync once that person has signed in.
The release programme
While TechieCRM is in its Alpha and Beta programmes the Cloud Connection window shows a line naming the current phase, whether it is free, and when the next phase begins, for example "TechieCRM is in its Alpha programme, free for invited and approved clients until 31 August 2026. Next: Beta from 1 September 2026."
Alpha and Beta members get the complete feature set, including cloud sync; the phase on your licence records which programme you joined under, not a smaller product. The 7-day account-setup trial is unchanged and runs alongside the programme.
The dates come from TechieCRM's servers, so they are always current; if the cloud cannot be reached the line is simply hidden rather than showing something out of date.
The window opens at once (October 2026 update). Reading the programme from TechieCRM's servers can take a few seconds on a slow or unreachable network, so the Cloud Connection window no longer waits for it before it appears: it opens straight away with "Checking the release programme..." where the line goes, and fills the line in when the answer arrives (or hides it, if the cloud could not be reached). Once read, the programme is remembered for 15 minutes, so opening the window again in that time shows the line immediately. Closing the window while it is still checking is fine: the check finishes quietly in the background and nothing else happens.
Beta builds also expire, on a fixed date
This is a separate rule from the release programme above, and separate from your licence. Every Beta build carries a fixed expiry date, set when it is built and shown on the beta notice each time TechieCRM starts (see Chapter 2). Every copy of the same Beta build stops on that date, whenever it was downloaded or installed, and whether it has ever been online or not.
What this means in practice: - If you keep using a Beta past its date, it will refuse to open, with a message telling you it has expired and offering a Download the current build button. - Installing a newer Beta (or the general release, once one exists) gives you that build's own date. - This has nothing to do with whether your licence is valid. A fully licensed, fully paid install still stops on schedule if the Beta build itself has expired; that is by design, so nobody is ever testing a stale build. - If no newer Beta has been published yet, the download page gives you the current released version instead, so you are never stuck with no working copy of TechieCRM. - A Beta also checks for a newer build each time it starts and lets you know if one is available, so you can usually update before the date arrives.