Chapter 25

The Mobile App (iPhone / iPad, preview)

Status: beta preview: it reads your real records, but does not write back yet. The app signs in with your real TechieCRM account and downloads your real data: clients, users, sales, service tickets, to-dos, marketing campaigns and your calendar. What is not built yet is the return journey: nothing you change on the phone is saved back, so treat it as a read-only window onto your workspace for now. Buttons that would create or edit say so when you press them.

All 22 modules are built. Every entry in the module menu now opens a real screen: its own lists, filters, record pages and functions. Nothing opens with a "not in this preview" note any more.

Being built and being fed are two different things, and the app is careful to tell you which is which. Seven modules carry your real workspace data today (Clients, Sales, Service, To-Do, Marketing, Calendar and Inventory) because those are the record types the phone downloads. Two further boards carry real records with part of their content still to follow: the Workspace board in Dashboards (your dashboards and indicators, by name) and the Knowledge Base board in Library / KB (an article's details, not yet its text). Three more work today by adding up what the phone already holds: Agenda, the Dashboards Summary board and the actuals half of Quotas. The remaining modules are finished screens waiting on their records to reach the phone, and each one says on screen exactly what it is waiting for, whether the hold-up is the phone's download, or your cloud workspace not carrying that kind of record yet. None of them ever invents a row to fill the space. The table under What each module can show you today is the whole picture in one place.

The phone requires an active cloud subscription and syncs with your cloud workspace only, never directly with a desktop PC.

Cloud (Aug 2026): this preview build is separate from a public App Store / Google Play listing; both are still pending final store approval. The public Download page shows each store's status and links to the listing the moment it goes live; every registered individual and company gets an email when it does.

Signing in

The app opens to a sign-in screen. Use the same email and password as the TechieCRM web portal; it is one account across the web, the desktop and your phone. Your password is not stored on the phone: it is exchanged once for a secure key kept in the iPhone's Keychain.

If your account has access to more than one workspace, the app asks which one to open.

If your account is switched off. Each time the app checks in with TechieCRM (when it opens, when you sign in, and when you come back to it after more than 15 minutes away) it also checks whether your TechieCRM account is still switched on. If an administrator has switched it off, the app signs out and the sign-in screen says "This TechieCRM account has been switched off. Ask your administrator." Records already on the phone stay on it, as they do after an ordinary sign-out; nothing is erased.

Your phone is registered to you (a tablet is shared)

A phone (iPhone or Android phone) is a personal device: when you sign in on it with your TechieCRM ID and password, it is registered to you. Each person can have one phone registered. A tablet (iPad or Android tablet) is shared, for example by people on different shifts, is never registered to a person, and is not counted.

Who is this phone registered to? Open Settings. Under Account the app shows Registered to and your name or email. A tablet shows that it is shared and not registered to a person; a phone nobody has signed in on shows that it is not registered.
A phone nobody has signed in on (for example one set up before this update, or whose sign-in could not reach TechieCRM) keeps working for 30 days. A bar at the top asks you to sign in on the phone with your TechieCRM ID by a given date. Tap the bar to sign in; records already on the phone stay on it. After that date the phone stops syncing until someone signs in on it.
If your TechieCRM ID already has a phone, signing in on a second one still signs you in, but the new phone is not registered. The bar says This device isn't registered to you. and then TechieCRM's own reason, for example "Your TechieCRM ID already has a phone registered to it. Remove it under My devices before registering this phone." Remove the old phone under My Devices in the web portal (your name menu ▸ My Devices), then sign in again from the bar.
When a phone that isn't registered tries to sync, the app says This device isn't registered to you. and what to do: sign in on this device with your TechieCRM ID, or, if your ID already has a phone, remove that phone under My Devices in the web portal first and then sign in here again. This is not a remote wipe: nothing is erased, you stay signed in, records already on the phone stay readable, and syncing resumes by itself once the phone is registered.
Removing a phone under My Devices erases TechieCRM's records from that phone the next time it connects, exactly as if it had been reported lost (see If this device is reported lost or stolen). Only remove the phone you no longer use.
If someone else signs in on your phone, it moves to them and you both receive an email.
Android builds made before 5 October 2026 never registered the phone. Update any Android phone in use: on an older build it stops syncing about 30 days after its first check-in, even if you are signed in.

Don't have an account? Tap Request an invite; sign-up happens on techiecrm.com, and accounts are invite-only while TechieCRM is in pre-release.

After signing in, your records download in the background: the client list first, then the other modules. The first sync on a large workspace takes a few seconds; after that only what has changed is fetched, so later launches are quick and the app works with no signal.

If a list shows "Partial sync", the download of that record type was cut short; your workspace holds more of them than that sync managed to bring down. Nothing is silently skipped: the phone never records a cut-short download as a complete one, so the next sync picks up from where it last knew it was up to rather than carrying on past the gap. Meanwhile the count tells you how many are on the phone, and the app calls it "Partial sync" rather than "Synced"; a capped download reported as finished would quietly claim your workspace is smaller than it is.

Some modules may be unavailable depending on your subscription.

A module still in beta testing carries a green "B" on its icon in the module menu (and in the iPad sidebar), just as on the desktop's icon bar and the website. Everyone sees the B, including beta testers, so you always know which modules are still being tested. If you are a beta tester, the module opens normally. If you are not, its icon is also dimmed, and tapping it does not open it: the phone shows "This function is currently in beta testing and is not available for general client access until it has been thoroughly tested." The menu stays open so you can choose another module. Links from other modules that lead to a beta module (a linked sale or project, Calendar's To-Dos button) show the same message. VoiceOver and TalkBack read such a module as, for example, "Projects, beta", and add "in beta testing, not available yet" when it will not open for you. The phone learns which modules are in beta each time it checks in with TechieCRM; if it has not been able to check in yet, no module is marked. (On the desktop and the website a non-tester can open a beta module to look at it, view only; the phone shows the message instead.)

A module your plan does not include is locked, just as it is on the desktop's icon bar. It stays in the module menu, dimmed and with a 🔒 lock, so you can see what your plan leaves out. Tapping it does not open it; instead the phone tells you why, in the desktop's words, for example "Projects is not included in your Starter plan. Upgrade in the web portal to enable it." The phone learns your plan each time it checks in with TechieCRM; if it has not been able to check in yet, nothing is locked. Upgrading on the web unlocks the module at the next check-in (the next time you open the app).

Light and dark

The app follows your phone's own appearance. When your iPhone, iPad or Android phone is set to Dark (iPhone and iPad: Settings ▸ Display & Brightness; Android: Settings ▸ Display ▸ Dark theme), TechieCRM turns dark too, and it switches the moment the phone does, including when the phone changes on its own at sunset. The colours are the same dark set the desktop and the web use for their Dark theme, so a record looks the same on all three.

A few things deliberately look the same in both: the dark bars at the top of each screen, the module menu and the sign-in screen are dark either way, and the orange highlight and the peach selection keep their colour with dark text on them.

Android builds made before 15 October 2026 are light only, whatever the phone is set to. Update any Android phone or tablet to a current build to get the dark appearance. From that build the Android app also uses the darker green for links and client names (the bright button green was too faint to read as text on the grey list background).

The accent colour is green, the same default green as the desktop and the web (buttons, links, your own chat bubbles, today's date). The phone does not offer the desktop's Primary and Accent choices or its extra themes. State colours keep their meaning and do not follow the accent: blue still means "in progress" or "not done yet" (a to-do still to do, an assigned ticket, a new work order, a running campaign, an open invoice), and Knowledge Base documents keep the desktop's record blue.

Every piece of text, in both light and dark, is at least 4.5 times brighter or darker than what it sits on (the WCAG AA standard), including grey dates and captions, links, and the words in status badges. The Theme chosen in the desktop's Settings does not change the phone; the phone's own setting decides.

The mobile app has no tab bar and no menu screen. You move between modules the way you work:

Swipe in from the LEFT edge → the module menu (the same icon bar as the desktop, all modules listed top to bottom) slides in over the whole screen while your current module slides away. Scroll it like any list; tap a module to load it; scrolling never opens anything. Swipe it back toward the left edge to return to where you were.
Swipe in from the RIGHT edge → the control bar: this month's mini calendar, your call list, today's meetings, and AR/AP items. Tap a call-list entry to jump to that client; tap a meeting to open the Calendar. Swipe back toward the right edge to return.
Inside an open record, the left edge does two jobs: swipe in from the bottom-left to go back to the module's list; swipe in from the middle-left for the module menu; from there you can jump straight to any module, or swipe it away to land back in the record.

On a full-screen iPad the same two swipes give you the same two panels, but they stay. Instead of sliding over your module and away again, the module menu becomes a column down the left and the control bar a column down the right, with the module you are working in between them, the desktop's own shape. Both can be open at once when the iPad is wide enough; on a narrower one (an 11-inch or a mini held in portrait) they open one at a time so the module in the middle stays usable. Swipe a column back toward its edge to collapse it. Choosing a module from the menu leaves the menu up, exactly as the desktop icon bar does. An iPad in a narrow Split View or Slide Over pane behaves like a phone instead.

A safety net you should never see. If the app is ever asked for a module it does not recognise, it says so plainly: a screen headed "Unknown module" naming what it could not match, explaining that it is not one of TechieCRM's modules, and offering a Go to Clients button. The swipe from the left edge works there too, so there are two ways out. Nothing you can tap produces this screen: the module menu only ever offers real modules.

Filtering a list by record type

The chips above a list are on/off switches, not a row of buttons where only one wins. Tap Companies and Contacts and you see both; tap Individuals as well and you see all three. Tap one again to switch it back off.

All turns everything back on. When every type is on the list is unfiltered, and the All chip is the one highlighted, so the row always tells you at a glance whether you are looking at everything or at a subset.

Switching off the last remaining type brings everything back rather than leaving you with an empty screen. There is no way to end up looking at nothing.

Which entries count as Contacts. Every person filed under a company or individual is a Contact, whichever of the source CRM's three contact codes it carries, so the phone, the desktop and the web portal all put the same people under the Contacts chip. (Before 4 October 2026 Android showed people stored with the least common of those codes as "Other", with a plain grey icon and no status, and hid them whenever a type chip was narrowed.) An entry that is not a client entry at all, such as an alternate address, still shows as Other with that plain grey icon: it appears under All and is hidden by any narrowed selection, because it is none of the types chosen.

Users are one of the types. They are the people who log in to your workspace rather than entries in your address book, so they appear alongside your clients when the Users chip is on, and they do not open into a record.

Working a list

Every module list works the same way:

Tap a row to open the record.
Hold a row for about a second: it lifts with a green outline ("armed"), then slide it: slide right for the quick actions on the left (e.g. Call / Text on a client), slide left for the actions on the right (e.g. Note / To-Do / Delete; on a To-Do: Complete / Move). A plain swipe without the hold never moves a row, so it can't be confused with the edge swipes.
The bottom bar is that module's functions, e.g. in Clients: Add Client · Note · Email · To-Do · Actions; in Sales: Add Sale · Note · Stage · Close · Actions. Press a function to run it; hold it for its variants (hold Add Client → Company / Individual / Contact; hold Close → Won / Lost / Abandoned, see Closing a sale on the phone). Actions opens the module's full action list.
The icon at the start of a row tells you how that record is doing, and its colour says the same thing again. The colour is the record's status and is never re-coloured to match a company's branding.
When nothing special has happened to a record, the picture is its module's own drawing: a ticket that is simply assigned shows the same wrench as the Service entry in the module menu, an open sale the same Sales drawing, a campaign the Marketing megaphone. When the record has a state of its own, the picture changes to show the state, which is the more useful thing to know at a glance:
Service: wrench (assigned) · ! (escalated, red) · tick (resolved, green) · clock (unassigned or open, grey) · hourglass (waiting on the customer, or on pre-authorisation) · telephone (call back) · bin (abandoned) · tick in a circle (closed). A status the phone cannot name draws the plain grey Service wrench, and the row prints your workspace's own word for it rather than relabelling it something the phone does recognise, unless the record carries a date saying the ticket was resolved or closed, in which case the phone reads it as finished. See A ticket on the phone.
Sales: the Sales drawing (in progress) · tick (won, green) · ✕ (lost, red).
Clients: the picture is the KIND of record, in the desktop's own full-colour record drawings (not tinted, and not the Clients drawing): a building for a company, one person for an individual, a person with a small building for a contact. The same drawings head an open record. A gold star over the corner marks a Prospect: a Company or Individual whose Client Status is Prospect, and a contact whose company is (the star follows the status itself, so it stays if your workspace renamed "Prospect").
Marketing: always the megaphone; only its colour changes: blue while running, green once completed, amber when suspended, grey when it has not started or has been cancelled or abandoned.
To-Do: always a clipboard; the mark on it is the state; see the next bullet.
A To-Do row shows its state as the mark on the clipboard: a tick (grey) is done, a cross (red) is overdue, a question mark (blue) is still to do and not yet late. The clipboard itself never changes, so a mixed list still reads as one kind of thing. Its priority HI in red, MED and LOW in grey) is written as text on the right of the row rather than drawn, because high, medium and low have an order and words carry an order better than shapes do. A to-do whose priority is blank, or is a code the phone does not recognise, shows nothing there rather than guessing. Chapter 15 covers the To-Do list in full. (Android builds made before 15 October 2026 drew a green tick for a done to-do, showed the priority as the row's badge instead of the state mark, and marked every to-do on a client's Interactions list with a green checklist whatever its state. Current Android builds draw the marks described here.)

Clients on a full-width iPad

On an iPad with enough width to show it (not a narrow Split View or Slide Over pane, which get the same single-column list a phone does), the Clients list renders as a table instead: the SAME columns as the Column Setup you use on the desktop's Clients list, in the same order, sorted by its leading column. If you have your own Clients column setup it is used; otherwise the workspace's default view is used; if neither has reached this device yet, you see today's single-column list (never an empty table). As the window narrows (a Split View pane getting smaller, for instance) columns drop off the RIGHT one at a time to keep the table readable; the leftmost, identifying column (the one with your name/company on it) never disappears. Swipe actions (Call/Text, Note/ To-Do/Delete) work the same way on a table row as on a phone row. City, Province, Country, Postal Code, Address, Territory, Website, Account Manager, Creator, Division, Sales Lead, Territory Status and Read Priv (the desktop's ReadPriv column, labelled the same way here as on the record screen's Basic tab, see below) columns now fill in from the same sync as the rest of the list, so a setup that uses any of these shows real data, not a blank column. A column your desktop setup asks for that this device genuinely cannot fill in (a User-Defined Field, or a field (such as the desktop's separate Full_Access column, a DIFFERENT column from ReadPriv even though both answer the same "Full Access" question on the desktop screen) that the source CRM tracks but this app's cloud connection does not carry yet) still shows blank rather than a guessed value; the column itself still appears, labelled "Full Access" (its own desktop name), in its place, matching your setup. (Before 6 September 2026 the ReadPriv column was mislabelled "Full Access" here too, the same name Full_Access uses; the two columns are now labelled differently, matching the record screen.)

Working a record

Inside a record the data itself is the control; there is no toolbar of buttons:

Phone numbers, emails, websites and addresses show in green (the theme's accent colour, as on the desktop). Tap a number to call it; hold it to choose Phone Call or Text Message. Tap an email to write one; tap a website to open it; tap an address for the map. Green client or contact names jump to that record (e.g. from a Sale straight to the client).
Hold any field and slide left for field actions (Edit · Copy · Share).
The bottom tabs are the record's sections: Basic · Related · Interactions · UDFs · Activities (a campaign shows Members instead of Related). Press a tab to open that section. Hold a tab to act on it: hold Basic to open the record in edit mode; hold Interactions for the add sheet (Add a Note · Attach a File · Take a Photo · Choose a Picture · Record a Voice Memo · File an Email); hold Activities for New Meeting / New To-Do.
A To-Do opens as a small editor sheet over the list instead of a full screen; complete it or save from there.

Key Fields: choosing which fields a record shows

The Basic tab is headed "KEY FIELDS FOR:" followed by the name of the field list in use. The name itself is the button; press it to switch to a different list. (There is no separate "Change" button.) Only lists that apply to the record in front of you are offered, so a list built for companies is not proposed on a contact.

Your choice is remembered for your login and, like the desktop, is remembered separately for companies, individuals and contacts, so choosing a company list does not change what you see on your contacts.

If the header reads "Standard fields", your workspace's Key Field lists have not reached the phone yet; press it and it will tell you why. The record shows its usual fields in the meantime.

Fields kept off the phone. A few user-defined fields are deliberately never sent to a phone: password and credential fields such as Admin PW or Service PW. They stay in the desktop, which reads them directly from your CRM database. If one appears in a Key Field list, the phone shows "Kept on the desktop (not synced to devices)" in place of the value, so you can tell the difference between a field that is empty and a field you simply cannot see from here. Nothing else about the record is affected, and the field is untouched on the desktop.

If a Key Field list shows fewer rows than you expect, that is the phone dropping fields this particular client has no value for, rather than the list being wrong.

What each section shows, and when it loads

The first time you press Interactions or Activities on a record, the phone fetches that client's history; it is not carried around with the client list, because a workspace holds hundreds of thousands of notes and documents and no phone should be carrying all of them. It arrives in about a second on a normal connection, and it stays on the phone afterwards: press the tab again, or come back to the record tomorrow with no signal, and it is already there.

Section	Shows	Comes from
Basic	The record's own fields	Downloaded when you open the record
Related	The company and its contacts	Already on the phone; works with no signal
Interactions	Notes, documents, emails, texts, to-dos, meetings, sales and service tickets filed against the client, newest first	Fetched when you first press the tab
UDFs	The client's user-defined field values	Arrives with the record
Activities	Just the scheduled work: meetings and to-dos	Same fetch as Interactions

Each row carries an icon for what it is (a note, an email, a text message, a document, a to-do, a meeting), who filed it, and its date. If a section is empty it tells you why: a client with no notes and a section that could not be reached say different things, and never look the same.

A to-do on this list reads exactly as it does on the To-Do list: the same clipboard with the same mark on it: a grey tick for done, a red cross for overdue, a blue question mark for still to do. Its priority is written the same way too (HI, MED, LOW, or nothing at all when the record does not carry one the phone recognises). Before 29 August 2026 this list drew the green done tick on every to-do and printed the priority exactly as it was stored, so the same task could say "done" here and "overdue" on the To-Do list, and read H here and HI there. One record now says one thing wherever you look at it.

A client on the phone

The line under a client's name. A company or an individual shows its type and, where the phone has downloaded them, its city and province. Until those arrive (or when the record simply has none) the line shows just "Company" or "Individual" rather than stray punctuation. A contact shows the company they belong to.

Email and website slots that show as Basic, not as UDFs. Your CRM database stores a client's primary email, second and third email, and website as user-defined fields internally, but they are not custom fields, and the phone now shows them the same way the desktop's Clients screen does: as part of Basic, not on the UDFs tab. - A second or third email address appears in Basic under its own name ("E-mail Address 2" / "E-mail Address 3") and is tappable to write to it, exactly like the primary Email row. - Website appears in Basic and is tappable to open it. - If your workspace's primary email is already showing under Email in Basic, it will not also print a second time near the bottom of the section; the same address is never shown twice. - Everything else stored as a genuine user-defined field for the client (the fields you or your CRM administrator actually created) stays on the UDFs tab, unaffected. (Before 6 September 2026 all of these showed on the UDFs tab, mixed in with your own custom fields.)

Division, Territory Status, Sales Lead and Read Priv. Four more classification fields from your CRM database now appear in Basic, right below Email, shown exactly as stored, with no attempt to translate a code into a word your workspace has never published: - Division prints the client's division name. - Territory Status and Sales Lead print the client's raw status code (for example "0" or "1"). Neither has a published list of what each number means, so the phone shows the number itself rather than guessing a label. - Read Priv prints the client's raw access-level code the same way. It is shown for reference only; it never changes what you can see or do with a record on this device. (This is a different field from the desktop's separate "Full Access" column, which the phone cannot show yet.) A client with no value for one of these four rows simply does not show that row, never a blank line, "N/A" or "Unknown".

Opening a client from somewhere else. When you tap a contact under a company, or tap a name in the call list while you already have a record open, the new record opens clean. Anything you had started on the previous record (an edit you had begun, for instance) stays with that record and does not follow you. The section you were reading does follow you: if you were on Interactions and you tap another client's name, you land on that client's Interactions, and their history is fetched for them rather than showing you a stale or empty tab.

How much history the Interactions tab holds. It shows the most recent 25 of each type. A line at the bottom of the tab says so, and names the record types the desktop also files here (marketing, projects, quotes, invoices, work orders and agreements), which the phone cannot yet retrieve for a single client. This is deliberate: the tab tells you what it is not showing rather than presenting a partial history as a complete one.

The notes include the note filed with each email sent to the client ("An email has been sent to …"), as on the desktop. These sent-email notes have their own limit: the tab brings the 25 most recent typed notes and, beside them, up to 25 sent emails, so a client who has been sent hundreds of emails still shows its typed notes (October 2026 update; see Chapter 17, Sent-email notes on the web portal and phones). On the iPhone and iPad each of these rows is labelled Sent email and carries the email icon, so it reads as the email it records rather than as a typed note; it stays under Notes in the All Types filter.

On Android phones and tablets (builds from 25 October 2026) these rows are labelled Sent email and carry the email icon too, and stay under Notes in the All Types filter. Android brings up to 100 typed notes and, beside them, up to 25 sent emails.

Filtering the timeline by type. Tap All Types at the top of the Interactions tab to choose which types you want to see. Any combination can be on at once. Turning the last remaining type off turns them all back on, so the list can never be filtered down to nothing with no obvious way back. When a filter is hiding rows the count beside the control reads "7 of 8" rather than just a total, and if your selection hides everything the tab says how many interactions are on the record and that your type selection is what is hiding them, never "this client has no interactions".

A company's timeline versus a contact's. Opening a company shows that company's own records plus those of the contacts filed under it. Opening one contact shows only that contact's.

The Related tab reads straight off the phone's own database, not a copy held in the app's memory, so it stays correct the moment a contact is added or the client list is re-synced, even while you are already sitting on the tab, and a brief "Loading related entries…" may flash the first time you open it on a record. It still needs no signal either way: the lookup never leaves the phone.

Adding a client from the phone

Tap Add Client in the bottom bar. The dialog asks for the Type Company, Individual or Contact) and a Name; Save stays greyed out until both are answered. If you already know which kind you want, hold Add Client instead and pick Company, Individual or Contact straight from the list: the dialog then opens named for that type, so a company is asked for a company name and a person is asked for a last name and a first name. The same hold menu still offers Import from Contacts, which brings someone in from your phone's own address book.

The dialog carries the record's name and job title, its email and up to four phone numbers (each with its own label, which you type; your workspace's labels are whatever your staff have used), the full address, Website, Salutation, Category, Status, Source, Territory, Department, and who the record is Assigned to (your own name by default). A Private switch at the bottom keeps the record to yourself.

Once the record is saved the app refreshes your client list and opens the new record, so you can see straight away that it is really there.

Adding a contact. A contact must say which company or individual it belongs to, and Save stays unavailable until you choose one. The quickest route is from the company itself: open it, then hold the Related tab and choose Add Contact; the dialog opens already filed under that company. (Holding Related while you are looking at a contact files the new one under the same company, not under the contact: the source CRM has no contact-of-a-contact.)

What the phone cannot do for a new contact. The source CRM allocates a contact's contact number and its workspace key, and it does that on the desktop's next sync; the phone cannot invent either without risking a clash with a real record. The dialog says so on its face. Until that sync happens the new contact appears under its company on the phone as normal, but a note cannot yet be filed against it; the Add Note dialog will tell you the same thing rather than saving a note nobody could find afterwards.

Changing a client from the phone

Hold the Basic tab on an open record. A bar appears across the top reading Editing this record, with Edit fields and Done. Tap Edit fields to open the record's own editor, already filled in with what it currently holds. Sliding a field sideways and choosing Edit arms the same bar.

Only what you actually change is sent. If you correct a phone number, that is all that travels to your workspace; every other field is left exactly as your colleagues left it, so an edit made on the phone cannot quietly overwrite a change somebody made on the desktop a minute earlier. Saving with nothing changed does nothing and says so.

Two things are deliberately not editable in a record's editor:

The type. A record cannot be turned from a company into a contact on a phone: that changes its key and re-homes everything filed under it.
The privacy switch. The phone is never told whether an existing record is private, so it will not show you a switch whose position it would be guessing at. Set privacy when you create the record, or change it on the desktop.

If you open the editor before a record has finished downloading, its address, Category, Source, Territory, Department and owner are shown as a short explanation rather than as empty boxes, and cannot be edited yet. That is on purpose: those fields arrive with the record's full detail, and saving an empty address over a real one would erase the street, the postcode and the country. Let the record finish downloading and open the editor again.

Deleting a client is done on the desktop. The Delete action on a client row says: "Records can't be deleted from the phone. Change the client's status instead, or delete it on the desktop." Nothing is changed. Deleting a record from a phone would remove it from every device and from the desktop, and that is not a thing the app will do on a single swipe.

New user-defined fields are set up on the desktop. Add Field on a client's or a sale's UDFs tab says: "New fields are set up on the desktop. Their values can be filled in here once they exist." On a campaign it says "Campaigns don't have user-defined fields." The Email button on the Clients list says the same as the Email module's New Message (composing is not on the phone yet).

A sale on the phone

The Sales list is every opportunity you have permission to see. A row carries the client, the objective and stage, the forecast revenue and the close date; the icon and its colour are the sale's state: the Sales drawing while it is open, a green tick once won, a red ✕ once lost. The All Stages / In Progress / Won / Lost chips and the search box narrow it, searching the objective and the client. When nothing matches, the phone says "Nothing matches" and tells you how many sales it is holding: a search that found nothing and a phone that has not downloaded anything are different problems and no longer read the same.

Opening a sale shows:

Section	Shows
Basic	Client, Status, Stage, Forecast Revenue, Actual Revenue, Cost, Close Date, Owner, Description
Related	The sale's client and its contacts, already on the phone, so it works with no signal. This is where a sale's contacts live; the Basic tab does not carry a separate Contact field, matching the desktop's own Sale dialog
Interactions	Notes, documents and emails filed against the SALE. Not downloadable from a phone yet; the tab says so and points you at the client's own history
UDFs	The sale's user-defined fields, including Confidence Rating, downloaded when you open the record
Activities	Meetings and to-dos on the sale. Same as Interactions: not downloadable yet, and it says so

Status is the sale's real status, in the same words the desktop uses: New · In Progress · Won · Lost · Abandoned · Suspended. The list's three-way colouring is a deliberate simplification for the row icon and the filter chips; the record itself never rounds a Suspended or Abandoned sale up to "In Progress". (Until 31 August 2026 it did.)
Leader and team are not on the phone. They are real fields on the desktop, but they are not yet part of the cloud sale record, so the phone cannot ask for them. The record says so under its fields instead of showing a name. (Until 31 August 2026 every sale in every workspace showed "Shannon Porter" as its leader and "Confident" as its confidence, neither of which was read from your data. Confidence now appears on the UDFs tab, where it actually lives, in your workspace's own wording.)
A sale with no client shows "This record has no linked client yet." (the same sentence as the desktop and the web portal), and the client line is not tappable, rather than jumping to a Clients screen with no explanation. A client the phone has not downloaded yet says that too.
Close dates read the same everywhere: "Sep 15", whether the record came from your workspace or from the demo set.

Closing a sale on the phone

(iPhone and iPad, 23 Oct 2026. Android phones and tablets get the same close in their own build; any difference is noted here when it ships.)

You can mark a sale Won or Lost from the phone, and the phone asks why, the same way the desktop and the web portal do (Chapter 4, When you mark a sale Won or Lost).

Three ways in, each asking Won, Lost or Abandoned:
hold a sale's row, slide it left and tap Close;
open the sale and tap Close beside its stage;
hold Close on the Sales function bar, pick Won or Lost, then pick the sale (sales already in that status are not listed). Pressing Close without holding says how to reach it.
The window shows the sale's name and:
Reason: the completion reasons offered for that status, from your office's list with the marks set on the desktop (Settings, Sales, Completion reasons). Hidden and removed reasons never appear. The reason the sale already has is chosen for you when the status still offers it. When there are none, the box is greyed out with "No completion reasons are set up."
Lost to (Lost only): (Unknown) and the sale's competitors. The phone lists the competitors already on the sale and cannot add one; add it on the desktop or the web. When the sale's competitors have not reached the phone yet, or it has none, a line under the box says so.
Close sale saves the new status with your answers. Skip reason still closes the sale and leaves the reason and Lost to as they were, the same as Skip on the desktop. Cancel changes nothing.
Abandoned is not saved from the phone yet: it shows a demo message and changes nothing.
There is no Close when your plan can read Sales but not change it, or when this build may not save to your workspace (see When the app says this build can't be used).
After you close it:
A sale created on the web or a phone turns Won or Lost at once.
A sale from your office database is sent to your office computer, which saves it there the next time it syncs. Until then the sale shows a Waiting for the office pill beside its name and keeps its old status, because that is still what your office database says, and Close is not offered again while it waits. Once the office computer has saved it, the pill goes and the new status, reason and Lost to arrive with the next sync. If no office computer is running, the change waits until one is.
If the office could not save it, the sale shows why under its name (for example "This sale no longer exists in the office database."). If someone changed the sale in the office in the meantime, it shows "Changed in the office since you opened it: now Lost" and nothing was changed. Dismiss hides the line on this phone only (your other devices and the web keep showing it until dismissed there); close the sale again if you still want to.
If your workspace refuses part of it, the phone shows the workspace's own sentence as it came: for example when your TechieCRM ID is not linked to a login in your office CRM (ask your administrator), or when a reason is no longer offered for that status. On a sale created on the web or a phone, the rest of the close is still saved.
With no signal the close is kept on the phone and sent when it next reaches TechieCRM; the phone tells you it is waiting to be sent, and Close is not offered on that sale until it has gone.
It is sent only to the workspace it was made in. If you sign in to a different workspace on the phone first, it stays on the phone and is never sent there.
If your workspace answers without taking it (for example the sale was changed somewhere else in the meantime, or your workspace refuses it), the phone stops trying and the sale shows the workspace's sentence with Try again (send it once more) and Dismiss (throw the close away on this phone).

A ticket on the phone

The Service list shows the ticket number and subject, then the client, the ticket's status, and its priority; the deadline sits on the right until the ticket closes.

The chips are All Tickets · Unassigned · Active · Waiting · Closed: four groups covering eleven statuses (Unassigned = Unassigned + Open; Active = Assigned + In Progress + Escalated; Waiting = Wait for Customer + Call Back + PreAuth Pending; Closed = Resolved + Closed + Abandoned). The row prints the exact status, so the grouping itself hides nothing.

The status is printed in your workspace's own words: the same list the desktop and the web use. When your workspace came from a source CRM, the phone downloads that database's own ticket-status list and prints each ticket's status exactly as that list spells it (so Wait For Customer stays Wait For Customer, not the phone's own spelling). An older web spelling such as in_progress is shown as the list's matching label. A status that is not on the list is shown exactly as stored, never reset; a bare number (an untranslated code from the source CRM) shows nothing. A web-only workspace's statuses are shown as each ticket stores them. The phone only shows ticket statuses; changing one is done on the desktop or the web. (Before version 0.8.0.2 the phone printed its own fixed spelling for the eleven statuses it knows.)

A ticket that was finished but never re-labelled reads as finished. A record can carry the day it was resolved, or the day it was closed, while its status word was left on an earlier state; the ordinary shape of a ticket brought across from your old CRM, where the finish is recorded as a date and the word is not always rewritten. The phone treats the date as the fact: such a ticket counts as closed, drops out of the open chips, loses its deadline, and prints Resolved or Closed rather than the older word your workspace still stores. That is the one place the phone shows a status it worked out instead of the word on the record, and it is deliberate: a ticket finished last week showing as live work, in the list, in the open count and with a running deadline, is the worse of the two. Three limits on the rule, so it cannot do more than it should: a word that already names a finished state is never overwritten (a ticket stored Abandoned stays Abandoned); a blank or empty date is not a date, so it changes nothing; and nothing is written back to your workspace; the record itself is untouched, and the desktop still shows the word it always did.

A ticket on a client's own timeline now agrees with the Service list about it. The Interactions tab reads a ticket by exactly the same rule, so the same ticket cannot say Assigned in one place and Resolved in the other. (Until 7 September 2026 it could, and did, for every ticket finished by a date rather than by a word.)

(Until 31 August 2026 a ticket whose status was literally Unassigned displayed as Assigned, and Abandoned, Wait for Customer, Call Back and PreAuth Pending all displayed as Unassigned. Both are fixed.)

Priority shows only when the ticket carries one; Urgent and High also earn a coloured badge on the record; a blank priority, or one the phone does not recognise, shows nothing rather than a raw code. ⚠ Ticket priorities do not reach the phone yet for tickets migrated from the source CRM: the cloud copy carries the numeric code and the phone reads the word, and the record screen says so rather than leaving you to wonder.

Three different empty lists say three different things: a search that matched nothing, chips narrowed too far, and nothing downloaded. The last reports Service's own sync, and carries the server's own reason when it failed. (Before 31 August 2026 every module's header showed the CLIENT list's sync state, so a Service screen could report a problem that belonged to a different module.)

Opening a ticket shows:

Section	Shows
Basic	The list fields plus Severity, Owner and Description, which download in the background when you open the record
Related	The ticket's client and its contacts, already on the phone, so it works with no signal
Interactions	The cloud can look a record's history up per client but not yet per ticket, so the tab says so and offers to open the client
UDFs	The ticket's user-defined fields, from the same background download
Activities	Same as Interactions: not retrievable per ticket yet, and it says so

(Until 31 August 2026 these five tabs highlighted when pressed and went on showing Basic.)

Assigned To and Owner show the person's name rather than their login code, whenever your workspace's user list has reached the phone.

A campaign on the phone

Finding a campaign. The Marketing list has a search box and a row of state chips (All States · Not Started · Running · Completed · Stopped. Search looks at a campaign's name, its type and its status. The chips start with everything showing; tapping one turns that group off, and turning the last one off turns them all back on rather than emptying the list. When nothing is on screen the app says which of three things happened: nothing has downloaded yet, your search matched nothing, or your chips are too narrow.

Campaign states. A campaign is drawn in the colour of its state: blue while it is running, green when completed, grey when it has not started or has been cancelled or abandoned, and amber when suspended. The phone recognises the eight state words TechieCRM uses across the desktop, the web portal and the cloud. If your workspace uses a word the phone does not recognise, the row still prints your word and draws a neutral mark; it will never say a cancelled campaign is active.

Opening a campaign. A campaign has no parent client, so its second tab is Members rather than Related: the client entries in the campaign. Basic shows the campaign's type, state, start date, its members, its target audience, and how many emails went out and came back; anything the record does not carry is left out rather than shown blank. Budget, actual cost, owner, end date and description download a moment after the screen opens; while that is happening the header says "Syncing", and if it cannot reach your workspace it says "List fields only" and explains why.

Members, and what the phone does not download. A campaign can carry thousands of client entries, so its member list stays in the cloud: the Members tab tells you so plainly rather than saying the campaign has none. Open the campaign on the desktop or the web portal to see who is in it. Target Audience is a different number (how many clients the campaign is aimed at), and it is shown on its own row for that reason.

Interactions, UDFs and Activities each explain what they would show and why it is not there yet: the phone can only fetch a record's history through its client, and a campaign has no client. Open a member from the Members tab to see that client's own history. Campaign user-defined fields live on the desktop; the cloud campaign record does not carry them yet, so the phone cannot ask for them.

Client Status on the phone

Every Company or Individual in the Clients list shows its Client Status as a small coloured pill, using your workspace's own labels (for example Prospect, Active, Former client, Do not contact). A client nobody has given a status reads Not set. A contact shows its company's status. Older text typed into the phone's previous free-text Status box shows as typed, in grey, until someone chooses a status for that client.

The record screen shows the status as a pill beside the client's type, and as a Client Status line on the Basic tab; on a contact it adds "(from )".
The Status filter (signed in only) is a second row of chips under the record types: All statuses, each status in its colour, any retired status a client still carries, and Not set (which also catches typed text). Choose several at once; the header shows "N of M" when the list is narrowed. A contact is filtered by its company's status. On Android the chips wrap onto a second line when they don't fit; on iPhone and iPad the row scrolls sideways.
Changing a status on iPhone and iPad: open the client, hold the Basic tab, tap Edit fields, and choose from the Client Status list at the top of the editor. Only your workspace's current statuses are offered. Once a client has a status it can be changed but not cleared, so there is no "Not set" choice for it; a client without one starts with nothing chosen. A new Company or Individual starts on your workspace's default status (usually Prospect). A contact has no status of its own, so its editor shows its company's instead. Typed text from the old Status box is shown above the list, read-only, and stays until you pick a status.
The History note ("Client status changed from Active to Former client (from a phone).") is written by your workspace when the change arrives, not by the phone, so it appears in the client's Interactions after the next sync, exactly once.
If the workspace refuses a status (for example an administrator retired it a moment ago), the rest of your edit is still saved and the app says, in a message titled Client Status not changed, what the workspace said and that the status was left as it was.
A device that has never checked in with your workspace (it has never reached the internet since it was set up) cannot change a status yet: the rest of the edit is saved, and a message says the status was not sent. Connect, reopen the app and try again.
Changing a status on Android: read-only for now; change it in the desktop app, on the web, or on an iPhone or iPad. The statuses themselves (names, colours, which one new clients get) are managed by your administrator.
Where the labels come from: the phone downloads your workspace's status list each sync and keeps it for offline use. On Android, until the first sync it uses the four standard statuses. On iPhone and iPad, until the list has downloaded, a client's status shows in grey under the name the workspace last sent and cannot be changed, and the Status filter is hidden.

The first sync after updating the app downloads your client list again once, so it can show every client's status.

The To-Do list on the phone

Who a to-do is for. Each row's second line begins with the related entry: the client the to-do belongs to, or the word Personal when it belongs to nobody but you, exactly as the desktop's To-Do dialog shows it. If a to-do names a client whose record has not been downloaded to this phone yet, the phone leaves that space blank rather than guessing a name; the to-do is still shown, and the name appears once that client syncs.

When it is due. Dates are written the way you would say them: "Aug 19", "Sep 3". For a to-do that is coming up, the date sits on the right of the row; for one that is due today or overdue, it follows the related entry on the second line. It is never shown twice.

A to-do with no subject is listed as "(no subject)", the same way it appears on a client's Interactions list, so the row can still be seen and opened.

Opening a to-do. Tapping a row opens the To-Do editor sheet. As well as the subject, related entry, date and priority, it shows the two things that live on the fuller record: the Time the to-do is scheduled for, and the Details, the same Activity text the desktop dialog shows. A to-do entered without a time is Timeless on the desktop and shows a dash here, which is the same thing said a different way. If the rest of the record has not reached the phone yet, the editor says so in a line beneath the fields rather than leaving you to guess whether the to-do really has no time and no notes. (Until 31 August 2026 the editor showed neither the time nor the details.)

Most of the time there is no waiting: the phone quietly downloads the full record for every to-do due in the week ahead as part of each sync, so those open instantly and work with no signal.

Completing a to-do is not on the phone yet. Complete (sliding a row, the editor's button, or the bottom bar) says: "Completing a to-do from the phone is coming in the next update. Use the desktop or the web portal for now." Nothing is ticked. (Until October 2026 Complete ticked the row on screen with a "demo" note, and the tick was gone the next time the app opened: the to-do had never been completed anywhere. That has been removed so the phone never shows a change it has not saved.)

Calendar: Day view

Swipe left or right across the middle of the screen (not from the edge) to move between days. Hold an empty time slot to start a new meeting at that time; tap a meeting to open it, hold it for its actions. Today in the function bar returns to the current day.

Swiping in from an edge only opens the panels. Coming back from the module menu or the control bar leaves you on the day you left. (Until 31 August 2026 an ordinary-speed edge swipe also moved the Calendar forward a day, with nothing on screen to say so, and, worth stating because it is why it went unnoticed for so long, a slow, deliberate swipe never did it; only a normal or quick one.)

All-day meetings have their own strip at the top of the day, above the hourly grid. They are no longer drawn as a block on the timeline, because an all-day event has no time of day to be drawn at. If a day carries more than three, the strip shows three and says how many more there are. Because the strip sits above the grid rather than over it, holding an empty slot to start a new meeting works normally on a day that has an all-day meeting; before, one all-day meeting made that gesture unusable for the whole day.

An all-day meeting appears on the date it was booked for, wherever you are in the world. It names a date, not a time, so it no longer shifts a day earlier for anyone west of Greenwich, which was everyone in Canada and the US. A meeting booked all day Tuesday used to show on Monday and be invisible on Tuesday. Adding one to your phone's own Calendar now puts it on the same date, at the start of that day, rather than on the evening before.

A meeting that runs past midnight shows on every day it covers. It fills the rest of its first day and is labelled with the day it ends on, and the following day shows it at the top as Continues until…. (Until 31 August 2026 a two-day event was drawn as though it ended the same afternoon.)

A meeting starting before 7am or running past 7pm is drawn to the edge of the hours the day shows and labelled started earlier or continues, so a clipped block is not mistaken for a short meeting. The day view still shows 7am–7pm only, and a meeting that falls entirely outside those hours is not drawn on the grid.

The control bar's "Today's meetings" now says which kind of empty it is: "Your meetings haven't downloaded to this phone yet. They appear here after the next sync." before the first sync, and "No meetings today. Open the Calendar to see another day." once they have arrived. Before, both cases said the Calendar wasn't on the phone yet, which was untrue whenever the day was simply free.

⚠ There is no Week view, no Month view and no tablet layout yet. The View button's Week and Month options say "demo only" when pressed, and an iPad shows the same single Day view as an iPhone. This is a known gap, deferred to a future build.

A meeting you attend with others is coloured for YOUR OWN completion, not whichever attendee's flag happens to sit on the record. Before 4 September 2026 this only worked for the day the app happened to open on; swiping to any other day showed the wrong colour for anyone whose own completion disagreed with the record's representative attendee. Every day now agrees with what you marked, however you get to it.

Agenda: the start of your day

Agenda is your work day on one page, added up from the records the phone already holds, so it works today, with no signal, and there is nothing extra to download for it. It has four sections:

MEETINGS: today's meetings in time order, each with its time, subject and client. Tap one to open the Calendar on today. (A meeting has no record screen of its own anywhere in the app yet, so the Calendar day is the whole of what a tap can honestly do.) A meeting shared with others is coloured for your own completion, the same fix as the Calendar's Day view.
TASKS: today's to-dos, sorted by priority then time, each showing its state mark and its related entry the same way the To-Do list does. Tap one to open the same To-Do editor sheet you get from the To-Do module. Completed and overdue tasks are hidden by default, matching the desktop; if either is hiding something, the section says so and names the switch that brings it back, so an empty Tasks list never quietly means "your options hid them".
COMPANY ANNOUNCEMENTS: items in your Company Library whose title contains the word "Announcement", newest first. You get the title, the date and a tap through to the Library item; the body of an announcement is not carried off the desktop, so it is not shown here. When your workspace has none, you get the Welcome to TechieCRM card instead. On a phone that has not downloaded the Library yet, the section says that rather than showing the welcome card; a welcome card is a statement about your library, which an unsynced phone has never seen.
BUSINESS DASHBOARD: one row through to the Dashboards summary, rather than a second copy of the same cards that could drift out of step with them. The desktop's 🚗 Entrepreneur cluster is desktop-only and the page says so.

Choosing what Agenda shows. Hold Sections in the function bar to turn the four sections on and off; hold Options for the two Activities switches: include completed and include overdue. Turn all four sections off and the page explains that it is your settings, not missing data, that emptied it. Your choices are kept on this phone: they do not yet roam to the desktop or the web portal the way the desktop's Agenda settings roam between those two.

Not yet available: "show items for all users" (not available on any surface), and choosing Agenda as the app's start page; the phone still opens on Clients.

Dashboards

Dashboards has two boards, chosen with the chips at the top.

Summary is a scroll of cards computed on this phone from the records it holds, one card per module, each with a headline number and a breakdown: Clients (companies, individuals, contacts), Sales (open, won, lost), Service (open, high-priority, closed), To-Do (overdue, completed), Calendar and Marketing. Tap a card to jump to that module, the way double-clicking an indicator works on the desktop.

These cards never guess. A card prints a number only when its own records have finished downloading at least once. If they never have, if the last attempt failed, or if only part of the list arrived, the card shows – and says which of those happened, and when a download failed, it shows your workspace's own reason word for word. That is what makes a genuine 0 trustworthy: an empty diary today reads 0, an unsynced phone reads –, and the two never look the same. A ticket whose status the phone cannot name is counted as neither open nor closed, and the Service card says so out loud.

Workspace Dashboards lists the real dashboards and standalone indicators saved in your workspace, by name and owner. ⚠ Their values cannot follow yet, and the board says so. A source-CRM dashboard's numbers are produced by running its own saved query against your CRM database, which a phone never talks to; the settings that define each tile do not leave the desktop either. So this board can show you what exists and who owns it, and the desktop or the web portal is where you read the figures. For the same reason, indicators are listed flat rather than grouped under the dashboard they belong to; which tile belongs to which dashboard is part of that desktop-only definition.

The list itself does sync. Refresh, or the next automatic sync, asks for your dashboards and indicators by name the same way every other synced module does, and once that has run the board lists what your workspace actually holds. Only the numbers stay behind, for the reason above.

Refresh in the function bar runs a real sync. Creating and editing dashboards, and printing them, stay on the desktop; the buttons say so rather than pretending.

⚠ On an iPad, Dashboards renders as a single column of cards rather than a grid: it has no wide-screen layout of its own yet. Two parts of the app do have one: the side panels described under "Moving around", and the Clients list, which becomes a table.

The operations modules

Seven modules cover the work that happens after a sale: Projects, Inventory, Work Orders, Financials, Partners, Agreements and Compliance & SLA. They are all fully built, and they all share the same shape you already know: a searchable list with filter chips, guide rows whose icon and colour are the record's own status, a record screen with sections, and a function bar of that module's actions.

What they have in common, and it matters:

⚠ None of them downloads records to this phone yet, except Inventory's item list, as of 2026-09-06. Every other list is empty on real data and every one names its own reason; some are waiting only on the phone's download, others on your cloud workspace carrying that kind of record at all. Where the two differ, the screens say which. See Inventory, below, for exactly what does and does not sync yet.
A record's status is always printed in your workspace's own words. The filter chips group statuses so they fit a phone, and the icon colour simplifies further, but the row itself never relabels anything. A status the phone does not recognise draws a neutral mark, keeps your word, and (this is the important part) always shows, whatever the chips are set to, so it can never be filtered away with no chip to bring it back.
Links between records are live only when the other record is genuinely on this phone. A green, tappable name always goes somewhere. When the phone cannot reach the other record it prints the name plainly and says why, rather than offering a link that leads nowhere.
Creating and editing are not available on the phone. Every create, edit and status button explains the real behaviour it stands in for and tells you nothing was saved. Where the desktop has a rule the phone can genuinely check, it is checked for real; see Inventory and Financials below.

Projects

The Projects list carries the project name, its client, status and phase, how complete it is, and its due date, with chips for the six lifecycle states (Proposed · Planning · Active · On Hold · Completed · Cancelled.

A project record has five sections:

Section	Shows
Basic	Client, manager, team, status, priority, phase, the dates, the money, and, where they apply, the hold reason, completion notes and the linked sale
Phases	Each phase with its planned and actual dates and a status mark, and the milestones as diamonds
Timeline	A Gantt chart sized for a phone: planned work as outlines, actual work as bars coloured by phase status, milestones as diamonds, and a red line for today
Resources	The people, teams, partners and inventory assigned to the project, each with a role and an allocation
UDFs	Project user-defined fields, which have no route to the phone yet; the tab says so

The record's ⋯ menu carries the two hand-offs the desktop has (Create Service Ticket and Create Invoice), and their refusal conditions are checked for real: a project with no client, or with neither revenue nor a billing rate, is refused in the same words the desktop uses.

The desktop's second view, Project Plans, is a real toggle at the top of the list to an honest "not built" screen: plans have no route to a phone at all yet.

⚠ Projects do not download to this phone yet.

Inventory

The Inventory list shows each item's name, its type and SKU, its status, the quantity on hand with its unit, and its sale price. The chips are stock buckets rather than raw statuses (In Stock · Out of Stock · In Process · Sold-Gone) because seven statuses will not fit across a phone; the row always prints the exact status word. An item that is nominally available but sits at zero is marked out of stock in amber, the same way the desktop marks it.

An item record has three sections:

Section	Shows
Basic	Type, SKU, kind, status, location, owner; the quantity (read-only here, as on the desktop; stock changes only through movements); unit cost, sale price, stock value and margin per unit; the client it was sold or transferred to; its source batch
Ledger	The movement history (receipts, consumption, production and transfers) under a life-cycle totals card that rolls cost in and revenue out the same way the desktop does
Fields	The per-type custom fields defined on the desktop, which have no route to the phone; the tab says so

Receive Stock, Transform and Sell/Transfer are on the record's ⋯ menu and on the row slide. Nothing is saved, but the refusals are real: try to sell more than you have and you get the desktop's own message ("Only N available to sell."), not a demo toast.

✅ Updated 2026-09-06: your item list now downloads to this phone. Your cloud workspace registered Inventory's storage, and the item list (name, type, SKU, status, quantity, sale price, and which client an item was sold or transferred to) now syncs the same way Clients, Sales and Service already do. The header names Inventory's own sync state (Synced / Partial sync / Not synced / Last sync didn't finish), never borrowed from another module.

✅ Also updated 2026-09-06: the Types registry and the movement ledger now download too, quietly, with no screen of their own yet, the same "downloads ahead of any screen that reads it" shape your saved column layouts already have (see What each module keeps on the phone). Every item still carries its own type's name, so nothing on the list was ever missing for want of the Types registry. The Ledger tab's wording changed to match: it now says a movement's history "syncs to this device but isn't linked to items here yet", rather than the older, now-inaccurate "can't download yet": the ledger genuinely reaches your phone, it just is not yet matched up to the item it belongs to. Only the last one, each type's custom fields, is still a real gap (the Fields tab still says so); your cloud workspace has nowhere to put them yet, on any surface.

Work Orders

The Work Orders list is a dispatch list. A row carries the subject, the work-order number, the customer, the internal dispatch status, the total price and the scheduled day. Two different status ladders are at work, exactly as on the desktop: the chips filter by the status your customer sees (Open · Scheduled · In Progress · Completed · Closed) while the row's colour is the internal dispatch status (new and dispatched blue, accepted and on-site amber, completed green, cancelled grey). A non-Canadian order shows its currency code beside the money ("$900 USD").

An order record has three sections:

Section	Shows
Basic	Customer, the order's parent (a ticket, a project, an agreement, or standalone), priority, both statuses, the lead partner, scheduled and completed dates, site, zone, on-site hours, the not-to-exceed figure, total price and cost, and the description
Lines	The order's lines by type (product, labour, part, inventory, miscellaneous), with quantity, unit price, per-unit cost and line total, over a totals card that separates what the customer pays from what it costs you
Assignments	Who is on the job: role (the Lead is starred), assignee, status, assigned and completed dates, and the agreed amount, shown as "Not agreed yet" when nothing has been agreed, the desktop's own wording. On a brand-new order the empty state states the rule: only a Lead assignment moves an order to Dispatched

Tapping through works. A parent ticket opens the real ticket in Service; a parent project opens it in Projects; an inventory line opens the item in Inventory; the customer opens the client. The lead partner and any partner assignee open the Partners record (since 31 August 2026, when the Partners module landed. (Until then they opened the plain company entry in Clients, which was the right answer while there was no Partners module and the wrong one afterwards. The company record is still one hop away, from the partner's own Basic tab.) An assignee who is an employee rather than a partner still opens their entry in Clients, and a name the phone cannot look up at all is printed plainly rather than claimed to be "not downloaded yet", because sometimes there is genuinely nothing to look up.

⚠ Work orders do not download to this phone yet.

Financials

Financials is one register holding both sides of the ledger: money owed to you and money you owe. Two rows of chips narrow it: direction (All · Receivable · Payable) and status (Any Status · Open · Overdue · Paid). Rows arrive in the desktop's own register order, overdue first and then soonest due, and read like the desktop: "Invoice INV-00041 · Overdue (12d)", with the balance coloured by status.

Status is worked out fresh every time you look. Paid, overdue and open are derived from the balance and the due date, never trusted from a stored word that may have gone stale, so a document saved as "open" whose due date has since passed shows as Overdue here, exactly as the desktop would show it on its next refresh.

A document has three sections:

Section	Shows
Basic	The party (captioned Customer on an invoice, Vendor on a bill), the number, direction, status, issue and due dates, the money block, and the description. Total, Paid and Balance always print, including $0.00, because on a ledger a zero balance is a statement, not a blank
Lines	Each line with quantity, unit price, tax and total, over a totals card. An imported header-only document is shown the desktop's way: the header total as a single line marked "(no line detail)"
Payments	The payments applied to this document, with date, method, reference and the amount applied here. When one payment settled several documents it says so: "part of a $5,130.00 payment split across documents". A paid document whose payment records are not on the phone says exactly that, never "no payments"

Record Payment is on the ⋯ menu, the Payments tab and the row slide, and its refusal is real: a fully settled document refuses in as many words: "INV-00027 is fully paid. There's nothing left to record a payment against."

Lines that came from elsewhere tap through to where they came from: an inventory line to the item, a project line to the project, a sale line to the sale.

⚠ Financials is split down the middle on data. Invoices and payments are waiting only on the phone's download. Bills are waiting on the cloud too; your workspace does not carry them for sync yet. The empty states say which is which.

Partners

The Partners directory is the companies you have flagged as partners, in name order, with chips for Active · Prospect · Suspended · Inactive. A row carries the name, the partner type and status, the region (falling back to the country) and the rating; an unrated partner shows nothing there rather than a zero.

A partner record has three sections:

Section	Shows
Basic	The company (a live jump to its entry in Clients), type, status, rating out of 5, service areas, region, country, payment terms, currency, the date they were onboarded, and notes
Work Orders	Every order this partner has been assigned (number, status, scheduled date, their role and their own agreed amount), each a live jump to the real order. Read-only, because orders are raised from the customer side
Compliance	Their compliance verdict as a coloured card, and a way through to the full requirement grid in Compliance & SLA. This tab is there from the moment you flag a company, before anything has been recorded

A stored value your drop-downs do not offer is shown and kept, not replaced; that is this module's own rule on the desktop, and the phone follows it for type, status, compliance status and currency alike; an imported EUR partner still reads EUR. A partner with no status recorded reads Active, which is what the desktop does too.

Removing a partner flag is offered on the ⋯ menu and the row slide, and explains what it would do: the company stays in Clients; only the partner attributes go.

⚠ Partners do not download to this phone yet.

Agreements

Agreements is your register of maintenance plans and service contracts, in the desktop's own order: the active band first, then drafts, then paused, then the rest, soonest due first. Seven chips cover the states: Active · Draft · Paused · Expiring · Expired · Renewed · Closed. Each row reads the way the desktop reads: "Active · expires in 21d", "EXPIRED, not renewed", "Renewed → #66", "Active · overdue", with overdue in red beating every other colour.

Expiry is worked out as you look at it, so the register flips to EXPIRED the day after a term ends without anything being written anywhere. An agreement ending today counts as expiring, not expired.

An agreement record has four sections:

Section	Shows
Basic	Agreement number and type, the customer (a live jump), the service, the lead partner (a live jump into Partners), group, PO, status, price and cost per visit, currency, locations, the renewal chain either way ("Renewal of #21" / "Renewed by #66"), and the job scope, instructions and access notes
Schedule	The recurrence in plain words ("Every 2 weeks on Tue, Fri", "6 months after the last service") with the start, the end or "open-ended", the term, on-site time, how many days ahead visits are generated, whether generation is automatic, the last service and the next due date
Work Orders	The visits this agreement has dispatched, each a live jump to the real order
Generated	The generation log: what was due, which order it produced, when, and any note

Renew, Generate due now, Pause, Resume, Mark completed and Cancel are on the ⋯ menu, and each explains the real behaviour it stands in for: that renewing starts the next term the day after the last one ends, copies the plan, links the two and deletes nothing; that re-running generation never produces a duplicate.

⚠ Agreements do not download to this phone yet.

Compliance & SLA

Two engines behind one board, as on the desktop; chips at the top choose which board you are looking at.

SLA Board is your service-level trackers in urgency order, each with its status, its resolve-by stamp (red once it has passed) and the hours left: "Breached · -52.7 h". Chips cover all six tracker statuses. Opening one shows its target, the customer, the policy, the started / respond-by / resolve-by / first-response / resolved times, the paused clock where there is one, and an Events tab with the tracker's own history. Open record on the ⋯ menu takes you to the ticket, work order or agreement the tracker is watching, offered only when that record is genuinely on the phone.

⚠ The hours-left figure is computed on the phone and is always current, but the status word itself is not re-derived: working out an at-risk transition needs business-hours arithmetic against a policy the phone does not hold. So a stale "On Track" tracker can show a deadline that has already passed; the two are shown side by side rather than one being quietly corrected.

Partner Compliance is one row per partner with a rollup ("3/4 satisfied · 1 expiring") and the next expiry, worst first. Expiry Board is what is running out, with windows of Next 30 / 60 / 90 days and Expired only (60 days to begin with, the desktop's own default), soonest first, and "blocks dispatch" written on the rows that carry that stake.

Tapping a partner on either board opens their requirement grid: every active requirement, with this partner's own entry against it (a requirement they have never answered reads Not Started), its status, expiry, evidence and days left, headed by the count satisfied and the dispatch verdict: Eligible for dispatch, or Not eligible with the reasons. That verdict, and the expiry maths behind it, are computed on the phone, so an approval that lapsed since your last sync reads Expired rather than Approved. The partner's name at the top jumps back to their Partners record.

⚠ None of the four kinds of compliance and SLA record downloads to this phone yet. There is no policy browser on the phone.

HR & Payroll

HR & Payroll is one board with four views, chosen by the chips at the top (Employees · Timesheets · Leave · Payroll) and a record screen behind each.

Employees, in surname order, with position, department, employment type and pay. Opening one gives Basic (tappable email, phone and cell; emergency contact; department, position, a live jump to their manager, employment, dates, standard hours, location; and the links card: their CRM login, their entry in Clients, and their Partners record where they are also a field partner, each a live jump when the phone holds it), Pay (basis, rate, currency, commission, and their pay lines. The currency line is shown only when the record actually carries one; a record with none shows no Currency row at all rather than a blank one), Time (their recent days) and Leave (their requests).
Timesheets, newest first, each day rolled up in the desktop's own wording: "worked 9:00 · reg 8:00 · OT 1:00 · late 7m". Opening a day shows the roll-up, who approved or rejected it and when, the frozen rate, and the individual punches.
Leave, decision-first, each request with its type, span, days and status. Opening one shows the request, the two-level approval trail (the manager half and the HR half, each printed only once it has happened) and whether the balance was deducted.
Payroll, newest period first, with hours by kind and the gross. Opening a pay line shows the period, the pay date, the rate at period end, hours by kind, pay by kind with commission, allowances and deductions, who approved it, whether it is paid, and the payable bill it produced; a live jump into Financials when that bill is on the phone.

Approving, rejecting, punching, running payroll, marking paid, adjusting and voiding are all offered, and each explains the real rule it stands in for: that approved days are frozen, that only draft pay lines recompute, that voiding keeps the figures.

⚠ This module is split on data, and the split is uneven. Employees are waiting only on the phone's download. Timesheets, leave and payroll are waiting on the cloud; your workspace does not carry those three for sync at all yet, so nothing can reach the phone whatever it does. The two kinds of empty state are worded differently on purpose.

⚠ Leave balances, pay history, team names and the HR Setup lists (departments, positions, shifts, leave types, pay cycles, holidays, rules) live only in the desktop and have no route to a phone at all. Where a screen would show one, it says so in place rather than showing a bare code or an invented figure.

Quotas

The Quotas list is one row per quota: the name, the fiscal year and owner, the target, and how much of it has been achieved. The chips are the desktop's own three: My Current Quotas (the default), My Quotas and All Quotas.

Opening a quota shows the Basic tab (name, fiscal period, sales rep, target, currency) over a Performance card: closed sales (won only), lost sales, the percentage of quota, and both the weighted and unweighted forecasts.

The Sales tab lists the actual sales those figures were computed from, each one a live jump to the real sale, in three groups named for the figure each one fed: Won: in Closed Sales, Lost: in Lost Sales, and Forecast only: not in Closed or Lost Sales. That third group is not simply "the ones still open": it holds everything that reached this quota through its expected close date alone: open sales, abandoned and suspended ones, and sales already won or lost whose actual close date falls in a different fiscal year. When the group holds one of those last, a line under the heading says so and says that the other year's Closed or Lost Sales is where that money is counted.

The amount beside a sale is what that sale put into the figure its heading hangs off, not the sale's forecast revenue. A won sale shows the actual revenue that went into Closed Sales; a lost sale shows what Lost Sales counted for it: its actual revenue, or its forecast where no actual was ever recorded, and the row says which; a forecast-only sale shows its forecast. Each group therefore adds up to the number above it. A won sale with no actual revenue on the record shows a dash rather than $0, with a note that it added nothing: the record does not say the sale was worth nothing, and a confident zero would. (Until 7 September 2026 the third group was called "still-open" and every row printed the sale's forecast, so a column of numbers could not add up to the figure it was explaining.)

Half of this module works on real data today. The targets themselves are waiting on the phone's download, but the achievement figures are worked out on this phone from your real synced sales; so the moment targets arrive, the numbers beside them are live. The arithmetic is the desktop's, quirks included: the weighted forecast counts every sale regardless of status, which looks odd and is what the desktop actually does; the unweighted forecast counts only open sales; and a sale can feed this year's forecast and last year's closed total at the same time. New, In Progress, Abandoned and Suspended sales land in neither money column.

If the app cannot tell which quotas are yours, it says so and points you at All Quotas rather than quietly showing you everybody's under a chip that says "My".

Quotas cannot be created or edited on the phone, and they cannot on the desktop either; the web portal is where they are set up, and the button says exactly that. Milestones and team roll-ups are not available on any surface yet.

Order Desk: retired into Financials

The phone no longer has an Order Desk module (from version 0.8.0.2). On the cloud, orders, quotes and inquiries are handled inside Financials, and every TechieCRM surface (desktop, web and phone) drops its own Order Desk placeholder to match. Until then the phone's Order Desk was an empty shell with nothing in it on any surface, so no records or settings are lost. Use Financials (Chapter 7) and Sales (Chapter 4) for quotes, orders and invoices.

Messages

Messages is a chat list and a thread, holding both kinds of conversation in one list, the way the desktop holds them in one window:

Users: one-to-one messages between the people who log in to your workspace.
Clients (texts): SMS threads with client entries, sent and received through the cloud.

The chips at the top are the desktop's own: All messages · Users · Clients (texts). A row shows who the conversation is with, a preview of the latest message (trimmed at 60 characters), when it was, and an unread count; conversations are grouped per person and the most recent sit at the top. The header counts them: "N conversations · M unread". User chats are tinted orange and client texts green, as on the desktop.

Opening one gives you the thread, oldest at the bottom of the scroll: your messages on the right in green (the theme's accent colour), theirs on the left in grey, each with the date and time in your phone's own timezone. The header reads Chat: or Text: .

Who can see a client text thread: the people on it, plus anyone when the thread is unassigned, plus your workspace's master login, the desktop's own rule, carried over.

E-mail is not here. Filed email has its own module (below), and the emails the cloud sends on your behalf appear on a client's Interactions timeline.

⚠ The composer is there and Send explains itself. A chat is a note written back to your workspace and a text goes out through the cloud's SMS service; neither write path exists on the phone yet, so every press says which one is missing rather than appearing to send.

⚠ Messages do not download to this phone yet. Two smaller gaps worth knowing: marking a client text thread as read is a change to your workspace, so the phone cannot do it and the thread screen says so (user chats are marked read as you view them, because that is kept on the device, which is how the desktop does it too); and chat rows show user IDs rather than display names until user chats can actually sync. Group conversations, attachments, deleting messages, the supervisor user selector and the notifications bell are not built.

(Until 31 August 2026 the module menu showed a permanent 3 badge beside Messages. It was a number left over from an early mock-up, not a count of anything; it appeared on every launch of every workspace. The badge now shows your real unread total, and nothing at all when that is zero.)

Email

The Email module is the archive of emails filed in your CRM database: the same emails the desktop shows on each client under Interactions ▸ Emails, and the web portal's Email list still lists. It is not your live mailbox, and it is not the messages the cloud sends on your behalf; those ride a client's Interactions timeline.

On the desktop, Email is now your live mail (since October 2026: every account's inbox in one window, Chapter 12). The phone has not followed that change yet, the same as the web portal, so on the phone Email still lists filed emails. Your live mail needs your mail account's settings; those can now reach the phone (see Your mail accounts on your phone below), but reading and sending mail on the phone is a later step.

The list gives you subject, who filed it, the date and the size, newest first. Two chips set the scope: Current Client (the client you have open in Clients, and the phone keeps that up to date as you move around) and All Mail, with the count in the header. Current Client is on to begin with.

The search box filters by subject. Three different empty screens say three different things: no filed email at all, no client currently open (with choose All Mail as the way on), and a subject search that matched nothing. An email with no subject is listed as (no subject), the desktop's own words.

⚠ Opening an email shows its header (subject, sender, date, size) and the sentence "No additional detail available for this message." The body text is not carried into the cloud yet; the migration takes the details of a filed email but deliberately leaves the message body behind. That is the desktop's own wording for exactly this state (its Email Details window), and it is shown instead of an empty pane. To read the whole email, open it on the desktop from the client's Interactions tab.

⚠ Filed email does not download to this phone yet.

New Message and Live Mailbox are both in the function bar and both explain themselves: each needs the phone's own mail feature (to send, or to read your live mail), which is not built yet even when your account settings have arrived. Refresh runs a real sync. Filing an email to a client, creating a client from a sender, importing from Mail.app and the Outlook add-in are all desktop-side and are not imitated here.

Your mail accounts on your phone

October 2026, iPhone and iPad. Works once TechieCRM has switched mail account sync on for your workspace; until then nothing in this section appears. Android follows one step behind.

The mail accounts you set up on your computer (Chapter 12, Your mail accounts on all your devices) can follow you to your phone: each account's address, display name, servers, user name and password, and your signatures. They are sealed with a key that exists only on your own allowed devices; the TechieCRM cloud, your administrator and everyone else in your office cannot read a password. On the phone they are kept in the iPhone's protected storage (the Keychain; the device's own key lives in the Secure Enclave on phones that have one) and shown read-only under Settings ▸ Mail accounts. Reading and sending mail on the phone with them is a later step; for now the phone receives the accounts so that step has nothing to ask you for.

Allowing your phone. Sign in on the phone with your TechieCRM ID and password as usual. If your workspace has mail account sync switched on and you have shared your accounts from a computer, the phone shows Waiting for approval with a six-digit code and the addresses that are waiting. Open TechieCRM on one of your other devices: it shows Allow this device? with your phone's name and the same code. Check that the two codes match and press Allow; the accounts arrive on the phone within a few seconds. You also receive an email whenever a device asks. Not Now puts the screen away (everything else on the phone works meanwhile); Settings ▸ Mail accounts says the phone is still waiting and Show the code brings the screen back.

When none of your other devices is on. Press Use TechieCRM Password on the waiting screen and type your TechieCRM password: it unlocks your mail accounts on the phone. You receive an email saying your mail accounts were unlocked on a new device, and the cloud allows five tries an hour. This works once one of your computers has stored the unlock (it does so by itself the first time it shares after you sign in there); if none has yet, the phone says so and you allow it from another device instead.

Allowing another device from your phone. When one of your other devices asks, the phone shows Allow this device? with that device's name and its six-digit code. Compare it with the code on that device and press Allow, or Not Me if the request is not yours (it signs that device out of your TechieCRM ID at once; change your TechieCRM password afterwards), or Decide Later to be asked again the next time the phone checks in. If the code TechieCRM sent for a device does not match the device's own key, Allow is switched off and the screen says so.

What Settings shows. Settings ▸ Mail accounts lists each account's address, display name and kind (IMAP, POP, Microsoft, Google), and a line under it: Ready; Sign in to finish for a Microsoft or Google account, which arrives with its settings but not its sign-in (the providers tie a sign-in to the program that made it, so the phone's own mail feature will ask for one tap when it is built); or the POP note (two devices downloading one POP mailbox lose mail when one deletes from the server). It also shows how many signatures arrived, when the phone last checked, and anything that went wrong, in words.

When a device is removed. If you remove one of your devices (My Devices on the web portal, or Settings ▸ Email on a computer) and your phone is the next device to open, the phone changes the key that protects your accounts so the removed device can open nothing new, and then shows A device was removed with the list of mail accounts whose passwords to change at your provider, and the signed-in accounts for which to remove TechieCRM's access in the provider's security page. Copy the list puts it on the clipboard.

Starting over. If your shared mail accounts are reset from a computer (or by a root administrator, or by a password reset), the phone shows Mail accounts were reset with who, when and why. OK removes the accounts from the phone; when a computer shares its accounts again, the phone asks to be allowed again.

Signing out, and shared iPads. Signing out of the phone removes the mail accounts, the signatures and the sealed key from it (your other devices keep theirs). The phone keeps its own device key, so when you sign in again with your password it is recognised as the same device and needs no new approval; on a shared iPad each person has their own key, so one person signing out never affects another's approval. Signing out also tells TechieCRM straight away (October 2026): My Devices in the web portal shows the phone Signed out at once, while it stays allowed for your mail accounts. Without a connection at that moment the phone still signs you out, but My Devices keeps showing it signed in (you can press Sign out there yourself). A remote wipe (If this device is reported lost or stolen) and a switched-off account remove the device key too: the device is then new to your mail accounts and must be allowed again.

Where the phone checks. The phone learns about requests, approvals and changes each time it checks in with TechieCRM (when it opens, when you sign in, and when you come back to it after more than 15 minutes away), and, while it is waiting to be allowed, it asks every ten seconds for ten minutes. Nothing runs in the background.

Library / Knowledge Base

One module, two boards: Company Library above Knowledge Base, one above the other on the same screen, the same merge the desktop made when it folded the Knowledge Base into the Company Library panel. Both are open when you arrive; tap a board's heading to collapse it and get its space back, tap again to reopen. The heading stays visible at the top of the screen while you scroll its rows, so you can always collapse the board you're not reading. Collapsing both boards is allowed; the screen tells you to tap a heading to reopen one. The search box filters both boards at once, and each heading shows how many of its rows are currently showing.

Company Library lists your library items in name order: name, what kind of item it is, the file extension, the size and whether it is Public or Private. Opening one shows those plus the owner, who created it, the dates and the source path.

⚠ Two honest limits here. The desktop's folder tree cannot be represented, so items are listed flat and a footer says so. And the file itself is not carried into the cloud, so there is no preview and no opening a document on the phone; Open and Save As explain what they would do. Dashboard and dashboard-indicator entries are filtered out of this board; they are the Dashboards module's own storage rather than library documents, and they appear on the Dashboards Workspace board instead.

Knowledge Base lists your articles with their FP-KB numbers and a status filter (All · Draft · Published · Expired · Internal. Rows are coloured by format the way the desktop colours them: blue for a document, teal for a hyperlink, neutral for a standard article. Search looks at any field, and typing digits finds the article number: "42" finds FP-KB00042. Opening an article gives its details plus its content: a standard article's text, a hyperlink's live, tappable URL, or (for a document article) an honest note that the attached file is not on this phone.

⚠ The two boards are waiting on different things. Library items are waiting only on the phone's download. The Knowledge Base is waiting on the cloud; your workspace has no Knowledge Base storage yet, so nothing can reach the phone whatever it does.

⚠ Updated 2026-09-05: supersedes the Knowledge Base half of the note above. Your workspace's cloud now has a Knowledge Base collection, and this build downloads it; the Knowledge Base board is waiting only on the download, the same as Library items, not on the cloud any more. The article schema is still metadata-first, though: title, status and owner arrive, but an article's text, hyperlink or attached file is a follow-up and stays on the desktop for now, so an opened article can show its details without yet showing its content. Article numbers ("FP-KB00042") are also not carried by this schema, so a real article may show no number even though its details are otherwise complete.

Adding library items is not available on the desktop either (it is on that chapter's own "not yet available" list) and the button says so rather than pretending it would save. The Knowledge Base actions (new article, approve, copy, save as, email) describe the real desktop behaviour they stand in for.

Personal

Personal is one module with two boards, the desktop's own two tabs.

⚠ Journal is in beta, and there is nothing in it to read yet. It is being kept, not retired, while it is decided what it should be. The board lists nothing today and explains why on screen, and that is not a sync problem: nothing is missing and nothing is waiting to download.

The reason is worth stating plainly, because it changes what the word "Journal" means here. The marker all three parts of TechieCRM had been reading as "a journal entry" belongs to the source CRM's Journalling feature, which automatically files a note every time you send a message. So what sits under that marker in a workspace carried across from the old system is an email history, not a personal diary, and TechieCRM will not present it as your journal. The desktop's Journal tab is empty for the same reason, and says so in the same terms (chapter 19).

Journal entries written in the web portal are real, and they are safe. The web portal keeps its own journal and files each entry against the person who wrote it; those are genuine records and none of this affects them. The phone does not download them yet. This is also why the board is not simply being deleted; doing that would throw real writing away.

What Journal should become (an honestly-labelled email history, a journal TechieCRM stores itself, or something else) has not been decided, and nothing is being taken away while that decision is open.

Before 7 September 2026 the phone's Journal board was built on the same mistaken rule. On the phone the board was empty in a real workspace, because nothing downloads the notes it would have read; no one was shown their own email here. The rule was in place, and would have surfaced it the moment those notes began downloading; the desktop, which reads your CRM database directly, was genuinely affected. Both have been corrected.

The board keeps its filter chips (List All (the default) · Today · Yesterday · This Week · This Month, with a week starting on Monday), so that whichever way that decision goes, the board is ready.

Expenses is one month's expense sheet at a time, in account-code order, with a month stepper that crosses year boundaries. Each row shows the account, the month's total, the year-to-date figure for that account and (when the row has been edited since it first synced) when it was last edited. Expense rows are green and have no detail screen; that is the desktop's rule, not a gap on the phone, and tapping a row says so rather than doing nothing; "last edited" is shown on the row itself because there is nowhere else on the phone to put it.

Accounts read "code - description", the same column the desktop shows, for example "601 - Meals & entertainment". When your workspace has no description filed for a code, the row shows the code by itself, and a footer explains that; the desktop does exactly the same with that row. (An expense entered through the web portal stores its description as the code, so those read normally.) This changed on 2026-09-07: descriptions used to be missing from the cloud entirely, and the old footer said so.

⚠ The Expenses board does not download to this phone yet.

Creating and editing are not available on the desktop either for these two: creating a journal note (on the web portal, which does still keep its own journal) or an expense is a web-portal job today, and the phone's buttons say exactly that rather than appearing to save. Daily amounts, an expense detail view, per-user filtering, column setup and printing are on this chapter's own "not yet available" list.

What each module can show you today

Module	Built	Real data on the phone today
Clients	Yes	Yes: every client you can see
Sales	Yes	Yes
Service	Yes	Yes
To-Do	Yes	Yes
Marketing	Yes	Yes
Calendar	Yes (Day view)	Yes: last 12 months plus everything ahead
Agenda	Yes	Yes: added up from the meetings and to-dos already here (announcements need the Library)
Dashboards	Yes	Summary board yes, computed here. Workspace board names yes (2026-09-05), listing your real dashboards and indicators by name/owner once synced; its values are desktop-only
Quotas	Yes	Achievement figures yes, from your real sales. Targets waiting on the phone's download
Projects	Yes	Waiting on the phone's download
Work Orders	Yes	Waiting on the phone's download
Partners	Yes	Waiting on the phone's download
Agreements	Yes	Waiting on the phone's download
Compliance & SLA	Yes	Waiting on the phone's download
Financials	Yes	Invoices and payments waiting on the download; bills not carried by the cloud yet
HR & Payroll	Yes	Employees waiting on the download; timesheets, leave and payroll not carried by the cloud yet
Library / KB	Yes	Library waiting on the download; Knowledge Base yes (2026-09-05): article details, not yet their content
Personal	Expenses; Journal in beta	Expenses waiting on the download. Journal is in beta (2026-09-08) while it is decided what it should be; nothing in it to read today, and the board says why
Messages	Yes	Waiting on the phone's download
Email	Yes	Waiting on the phone's download; message bodies are not carried by the cloud yet
Inventory	Yes	Item list yes (2026-09-06): name/type/SKU/status/quantity/price/client. Types and the movement ledger also now download (2026-09-06), quietly, with no screen of their own yet. Custom fields not carried to the phone yet
Order Desk	No, retired into Financials (0.8.0.2)	–

"Waiting on the phone's download" means your workspace has the records and the cloud is ready to send them; this build of the phone does not yet ask for them. "Not carried by the cloud yet" means the records exist on the desktop but the cloud has nowhere to put them, so nothing can reach a phone until that changes.

⚠ The Dashboards row's Workspace-board half is now the first kind, not the second: as of 2026-09-04 the cloud carries your dashboards and indicators as their own collections, ready to send, and this build simply hasn't asked yet; see the Dashboards section above for the detail.

⚠ Updated 2026-09-05: supersedes the note above. This build now asks: the Workspace-board half has moved off this table entirely; it is real data on the phone today, same as the row now says.

⚠ Updated 2026-09-05. The Library / KB row's Knowledge Base half is now the first kind too: the cloud registered a kb_articles collection that day and this build downloads it; see the Library / Knowledge Base section above for what still doesn't arrive (an article's own content).

What the phone can WRITE today is a shorter list than what it can read. Everything not in the table either says plainly where it is done (the desktop or the web portal) or, for actions still being built, answers "demo only, nothing saved" rather than pretending. This table grows as each form is built (the plan is Real forms on the phones and tablets, October 2026):

What	Where on the phone	iPhone and iPad	On an office workspace
Add a Company, an Individual or a Contact; change a client	Clients	Saves	Stored in TechieCRM (sent to the office in a later update)
Add a Note	Clients, Sales, Service, Marketing, Partners, Projects, Work Orders, Compliance & SLA	Saves	Stored in TechieCRM (sent to the office in a later update)
Import a contact from the phone's address book	Clients	Saves	As adding a client
Close a sale as Won or Lost	Sales	Saves	Waiting for the office (see Closing a sale on the phone)
Complete a to-do	To-Do	Not yet: says so, changes nothing
Delete a client	Clients	Done on the desktop: says so
Add a user-defined field	Clients, Sales, Marketing	Done on the desktop: says so

Every one of those is subject to your plan: a read-and-delete plan can open the dialogs but the Save button explains that your plan does not include creating or changing records. If your workspace cannot be reached, what you typed is held on the phone and sent on a later launch; it is never thrown away.

On Android phones and tablets

(Builds from 25 October 2026.) Android saves the same way under the hood: one save path for every record, the same checks on every field as the iPhone, and the same queue for anything that cannot be sent yet. What Android can save today is shorter than the iPhone's list, because its forms arrive in the next updates:

What	Where on Android	Android phones and tablets	On an office workspace
Close a sale as Won or Lost	Sales	Saves	Waiting for the office
Complete a to-do	To-Do (slide a row, the editor, or the bottom bar)	Not yet: says so, changes nothing
Delete a client	Clients (slide a row)	Done on the desktop: says so
Write an email	Clients (bottom bar)	Not yet: says the desktop and web portal send email today
Add a user-defined field	Clients, Sales, Service	Done on the desktop: says so
Add a field to a campaign	Marketing	Says campaigns don't have user-defined fields

Everything else Android offers still answers "demo only, nothing saved" until its form arrives. When a form saves on Android:

on a phone it opens as a sheet from the bottom of the screen; on a tablet (a window at least 600 dp wide) it opens as a dialog in the middle of the screen, and on a wide tablet (840 dp and wider) related fields sit two to a row, such as Date beside From;
Save stays greyed until every required field is filled; a field you leave empty or overfill says what is wrong right under it;
when the workspace can't be reached, the form closes and says "Saved on this phone. It will be sent when you are back online." The record appears in its list at once with a Not sent yet pill, and goes on its own the next time the app syncs, checks in, or the phone gets its signal back. (On the iPhone and iPad the form stays open with the reason instead.)
if the workspace refuses the save, the form stays open with the workspace's own sentence and everything you typed.

A note on the holds

Anywhere this manual says "hold", it means a brief press, about a fifth of a second, not a long wait. The pause exists only so the app can tell a deliberate action from a scroll. Once a row has opened its buttons you can slide it straight back, or across to the other side, without holding again.

Data on the phone (how sync will work)

"Saved", "Saved on this phone" and "Waiting for the office". When you save a record, the app tells you which of three things happened, and they mean different things:

Saved: your workspace has it, and every other device and the web portal will see it.
Held on this phone: the app could not reach your workspace (no signal, or this build is not allowed to write right now). What you typed is kept on the phone and sent automatically when it can be; the dialog stays open with the reason, and nothing is thrown away.
Waiting for the office: your workspace keeps its records in your office's own CRM database (an office workspace; the phone learns which kind of workspace it is from its check-in). Your workspace has taken the change and passed it to the office computer, which writes it into the office database, usually within about 15 minutes, longer if that computer is switched off. The dialog closes and says "Saved. Waiting for your office to add it." (or "...to apply the change" for a change to an existing record). Nothing more is needed from you. The phone's to-do, meeting and ticket forms that use this arrive in the next updates; a sale closed on the phone already shows its own Waiting for the office pill.
Not sent to your office: on an office workspace, if your TechieCRM ID is not linked to a login in your office CRM, a new to-do, meeting or ticket is still stored in TechieCRM (nothing you typed is lost) but cannot be sent to the office, and the app shows the reason. Ask your administrator to link your login; your next change to that record sends it.

On Android phones and tablets the same four outcomes apply, with these differences (builds from 25 October 2026): a save held on the phone closes the form and the record shows Not sent yet in its list until it has gone; a held change the workspace then refuses shows Not sent with the reason, Dismiss and Try again, and is never retried on its own; and Not sent to your office is shown until the app is next opened (your next change to that record tries the office again either way). If the office computer is in the middle of adding a record you change on the phone, Android keeps your change and sends it once the office has finished, to the office's own copy of the record.

Times on the wire are always in UTC and converted to your phone's time zone on screen. A time you pick that does not exist on the day the clocks go forward (2:30 in the morning on a spring-forward day) is saved as the first time that does exist (3:00), and a time that happens twice when the clocks go back takes the first of the two; the desktop, the web portal and Android do the same.

When connected, the phone follows a tiered download: every client you have permission to read is always on the phone (just the list fields and relationships, a very small footprint), a record's full details download in the background when you open it, a client's history downloads when you first open its Interactions or Activities tab, and item bodies (a note's text, a document, an email) download when you tap them. Once something is downloaded it stays on the phone and is only ever updated when the cloud has changes; your edits push back to the cloud automatically. A cleanup setting for cached records will come later.

When your workspace keeps its records in an office database, a to-do, meeting or ticket you add on the phone waits for the office computer (October 2026 update). The phone saves it in TechieCRM straight away and shows it with a Waiting for the office mark; within about fifteen minutes of the office computer's next check-in the office desktop adds it to the office database and the mark goes away, and the record carries on under the office's own record number (a ticket gets its office ticket number then; until then the form says "Assigned when your office saves it"). A change you make to a record that came from the office waits the same way, field by field: if the office changed a field in between, the office's value stands and the record tells you. Not sent to your office means the record is safe in TechieCRM but could not be queued, and the line says why (usually your TechieCRM ID is not yet linked to an office login: ask your administrator, then change the record once more). Chapter 13 says what the office computer does with these. The forms themselves arrive in the builds that follow; this update is the office side, which must be in place first.

If your client count goes up after updating the app, that is expected: nothing was added to your workspace. Some early builds of this app could only hold the first 10,000 clients of a larger workspace; the record was still safe in the cloud the whole time, just not yet on that phone. An update repairs this automatically, once, the first time it runs: the phone re-downloads the client list in full and the count on screen catches up to what your workspace actually holds. You do not need to do anything, and nothing you had on the phone is lost while it happens.

Setting up a new Android phone from your old one does not copy TechieCRM's data. Android's "copy from your old phone" step and Google's cloud backup both skip TechieCRM on purpose, so your clients and your licence key never sit in a backup. On the new phone, open TechieCRM, sign in, and it downloads your workspace from the cloud as it did the first time. Nothing is lost: the records were always in your workspace, not only on the old phone.

What each module keeps on the phone

Clients, Sales, Service, To-Do, Marketing and (as of 2026-09-06) Inventory's item list keep everything you have permission to see, including sales and cases that have been open for years, because an old record that is still open is still your live work.

Calendar is the one exception to "everything". A workspace can hold decades of past appointments (this one holds over 25,000), which is more than a phone needs to carry. The phone keeps the last twelve months plus everything scheduled ahead of you, with no cut-off in the future, so a meeting booked years in advance is on your phone today. Older meetings stay safe in the cloud and on the desktop; they simply are not carried in your pocket.

No other module keeps records of its own yet, because none are sent to it yet (Inventory's item list, above, is the one exception as of 2026-09-06). Their screens are built and ready; what is missing is the download, and in several cases a place in the cloud for the records to sit at all. When each one is switched on it will follow the same tiered pattern as the six above: the list on the phone, a record's detail when you open it, and its history when you ask for it. Agenda, Dashboards and Quotas are the ones that already have something to show: they store nothing themselves and instead add up the six lists above, so they work today and will simply get richer as the rest arrives. The table in What each module can show you today says which is waiting on which.

⚠ Updated 2026-09-05: one more thing now downloads with no screen of its own yet. Your saved column layouts (which fields a list shows, in what order and how wide) started syncing to the phone that day too, ahead of any phone screen that reads them. There is nothing to see from this yet; it is quietly ready for the day a phone screen (starting with a wider iPad list) uses it.

⚠ Updated 2026-09-06: two more things now download the same quiet way. Inventory's Types registry and its movement ledger both started syncing to the phone, ahead of any screen that reads either directly. The ledger download is bounded to roughly the last year, unlike every other list on this phone (Calendar is the only other exception, described above); a stock ledger can run to thousands of rows per item over the years, and nothing reads it yet to justify carrying more.

If the phone has been offline for a very long time (added 2026-09-06)

The cloud keeps a record of what has been deleted from your workspace for a period of time after each deletion, so a phone that syncs reasonably often always finds out. A phone that has been switched off, in Airplane Mode, or simply not opened for far longer than that window would otherwise never learn a record was deleted on the desktop or the web, and could push it straight back the next time you edited it, undoing the deletion for everyone.

What you will see, and since 7 September 2026 you do see it. The phone notices this on its own the next time it tries to sync, re-downloads the affected lists in full, and removes locally anything the cloud no longer holds, while leaving any of your own not-yet-sent changes exactly as you left them (see "What still works" and "What you typed keeps showing on screen while it is held", earlier in this manual). The same automatic re-download also happens if an administrator asks the cloud to hand this device a completely fresh copy of a module.

It tells you. A message appears when the sync finishes, and a banner across the top of the app stays there until you close it with its ✕. The banner carries your workspace's own explanation of why, word for word, so the reason you read on the phone is the reason your administrator sees; if your workspace sent no reason, the phone says "This device is refreshing its copy of your workspace. It may take a minute." It is green when nothing went away, and amber when records really were removed from this device, in which case it also says how many and that they were removed because they had been deleted while this device was away. It never claims a record was removed unless one actually was. One sync produces one banner, however many lists were re-downloaded.

There is nothing to act on either way, but the banner does not time out, deliberately: a launch sync usually finishes while you are not looking at the phone, and a message that clears itself is one you never got. (Before 7 September 2026 all of this happened in silence.)

If instead you see "This licence isn't linked to a workspace yet.", that is a different, account-level problem, and a re-download cannot fix it. It means the sign-in this phone is using has not been connected to a TechieCRM workspace. Contact your administrator; simply reopening the app will keep showing the same message until the account side is corrected.

Times always show in your phone's timezone

Appointments are stored in universal time and converted to wherever your phone currently is. If you travel, the Calendar re-reads your meetings against your new local time, so a meeting always appears at the hour you will actually attend it, and on the right day.

If this device is reported lost or stolen (remote wipe)

If a phone or iPad is lost, stolen, or being handed on to someone else, an administrator can flag that specific device from the cloud side. The next time the app opens and checks in (whether or not anyone signs in during that visit), every record on the device is permanently deleted.

What you will see. A full screen saying "This device has been wiped", with the administrator's reason underneath if one was given. There is nothing to tap and nothing to configure; the screen is simply telling you what has already happened and that TechieCRM is confirming it with the server. It clears itself automatically the moment that confirmation goes through, and you land back at the ordinary sign-in screen.

Your unsent changes are sent first (from version 0.8.0.2). Before deleting anything, the app tries once to send any change made on the device that has not yet reached the cloud (a new or edited client, a note), so the workspace keeps it. That attempt is limited to about half a minute and shows nothing on screen. If it cannot finish in that time (no signal, a slow connection), or the app is closed while it is still running, the wipe goes ahead anyway: the next time the app opens, it deletes everything before it does anything else, so closing the app does not stop a wipe.

What is actually deleted. Everything TechieCRM has downloaded onto that device: every client, sale, ticket, to-do, campaign, calendar meeting, dashboard and indicator, Knowledge Base article, column setup, Client Status list, inventory item, inventory type and stock movement, and every downloaded record detail, the same tiered download described above, gone. So is the app's record of what it had synced (it starts from nothing when you sign in again), its remembered places and screen preferences, its cached files, and the screen snapshots iOS keeps of the app. Deleted records are overwritten in the app's database file, not just marked as deleted. (Builds made before 1 October 2026 missed dashboards, indicators, Knowledge Base articles, column setups, Client Status and the three inventory lists; on those builds, those stayed on the device.)

The app keeps only what it needs to finish the wipe and to stay the same device: the wipe's own record (so it can confirm the wipe with the server), the device's identity, and this build's entitlement check. None of them holds any workspace data.

Not reachable by a wipe. A meeting someone added to the phone's own Calendar with Add to Calendar, or a client saved to the phone's Contacts, belongs to that app now, not to TechieCRM. A wipe cannot remove it (TechieCRM is only allowed to add calendar events, not read or delete them), so remove those by hand if the device is being handed on.

Any change that could not be sent in that last attempt is deleted with everything else; this is a security action, not a bug, and there is no way to recover it from the phone afterwards (the record itself is untouched on the cloud, if it was never yours to lose in the first place; only this device's local copy is gone).

Every copy is destroyed, not just the working database (added 2026-09-06). A wipe now also removes an older cache file left behind from before the app's storage was rebuilt, and a small diagnostic log the app writes to help track down crashes; both were plaintext copies that could otherwise sit on the device untouched by a wipe. The diagnostic log itself has also been changed to never record an email address or a record's actual text (only a count, such as how many candidates were tried), and it is now protected so it cannot be read even from a phone backup.

Reinstalling the app does not get around a wipe or a suspended device. Deleting TechieCRM still erases everything stored on it, exactly as iOS always does. But the invisible identity the app uses to tell devices apart now survives a reinstall, the same way your sign-in credential already did; so deleting and reinstalling the app can no longer be used to dodge a pending wipe or a suspended device; it reappears as the same device it always was.

If the device is offline when this happens. The deletion still runs the moment the device does manage to check in; it does not wait for you to be connected first. If it cannot then confirm the deletion with the server (no signal, for instance), the "This device has been wiped" screen stays up and keeps quietly retrying every time the app is opened, until it gets through. Your records stay deleted the whole time; nothing is restored while waiting to confirm.

The retry also fires the moment the app is brought back to the foreground, not only on a fresh open; switching back to Wi-Fi and returning to an app already sitting on the wiped screen is enough to confirm the deletion, with no need to force-quit and relaunch first.

Signing back in. Once the device has confirmed the wipe with the server, it behaves like any freshly installed copy of TechieCRM: sign in again with your account to start syncing a fresh copy of whatever you currently have permission to see. A device can be flagged and wiped more than once, if it is lost and later found and reissued, for example.

On Android phones and tablets

Android builds made from 2 October 2026 behave as described above: the same "This device has been wiped" screen, the same wipe on the next open whether or not anyone signs in, the same retry on every open and every return to the app until the server confirms. Android builds made before then did not act on a wipe at all: a flagged Android device kept its records until the app was uninstalled. Update any Android device in use to a current build.

The differences on Android:

What is deleted. Every client, sale, ticket, to-do, campaign and calendar meeting on the device, every downloaded client detail, the user list, the Client Status list, your Key Field choices, the remembered place in each list, and the app's record of what it had synced. Then the app deletes everything else it has stored, not just the things it knows the names of: every settings file and every file in its own storage areas, so anything a later version adds is covered too. Each file's contents are overwritten before it is deleted. (Android does not yet download dashboards, the Knowledge Base, column setups or inventory, so there are none of those to delete.)
What is kept. Only the wipe's own record, the device's identity, the sign-in key, and the app's record of whether this build is allowed to run (builds from the check-in update onward; it holds no records, and keeping it means a wipe cannot reset a blocked or unconfirmed build). The key stays only until the server confirms the wipe (it is what proves the confirmation came from this device) and is then removed.
Unsent changes go first. Changes held on the phone (a sale close, and from 25 October 2026 any saved record that has not reached your workspace) are sent before anything is deleted, for at most 30 seconds; whatever cannot be sent in that time is deleted with the rest and counted in the wipe report.
Uninstalling. Uninstalling TechieCRM on Android deletes all of its data, as it always has, and also deletes the device's identity. A reinstalled copy therefore appears to the server as a new device, and the old device's wipe stays shown as not yet confirmed. Its data is gone regardless.
How the order arrives. The wipe reaches the device through the app's check-in with the cloud. If the cloud refuses that check-in (for example, a licence tied to one desktop computer), the order cannot reach the device; sign the device in with a licence meant for mobile use.

When the app says this build can't be used

The mobile app is a preview build. It is not from the App Store; it is installed onto your phone from the Mac it was built on. Preview builds belong to a release channel (Alpha first, then Beta, then the general release), and TechieCRM's server decides which channels are still allowed to run. When the programme moves on, an older build stops being an allowed build.

Which build am I on? Open Settings on the phone; the bottom line reads the version, the build number and the channel, for example 0.8.0.2 (3) · beta. The four-part version is the TechieCRM version shared by every TechieCRM product (desktop, web and phones move through 0.8.0.x together); the App Store itself only shows the first three parts (0.8.0), because Apple allows no more. That is the whole answer, and it is read from the app itself rather than typed in, so it cannot be out of date. An Alpha build is allowed only while the programme is in its Alpha phase; a Beta build is allowed through Alpha and Beta and stops at the general release. If you are asked which build you are running, that line is what to read out.

Nothing is deleted, and the app never becomes a dead end. If your build is no longer allowed, you get a read-only app: everything already on the phone stays there and stays readable.

What you will see

A yellow bar across the top of every screen. It is permanent; there is no way to dismiss it, because it is telling you something about the app that has not gone away. It carries TechieCRM's own words, exactly as the server sent them, so the reason you read on the phone is the same reason your administrator sees.

Tap the bar at any time to open the full explanation. That is true of every yellow bar the app can show: the expired one, the "hasn't reached the server in N days" one, and the "hasn't been confirmed yet" one on a new install. Each opens its own explanation, in its own words, and every one of them has a Close button.

The explanation opens by itself once, the first time you open the app after the block starts. You can close it and carry on. (The "hasn't been confirmed yet" bar never interrupts you; it only opens when you tap it, because nothing is blocked.)

What still works

Every record already downloaded (clients, sales, tickets, to-dos, campaigns, your calendar, and the history on a client's record.
Searching, filtering and Key Field lists over those records.
Saving a client to your phone's Contacts, or a meeting to your phone's Calendar, if your workspace allows that. Those copy information the phone already has; they change nothing in the CRM.
Signing in, and checking in with the server. This is what lets the app un-block itself. The moment the server says this build is allowed again (for example because an administrator moved the programme dates), the app goes back to normal on its next launch. You do not need to do anything.

What stops

Adding or changing anything. The Add buttons disappear from the bar at the bottom of every screen.
Downloading new or updated records. What is on the phone is what you have.

If you had just added something and it could not be sent, the app keeps it and the yellow bar adds a second line ("1 change not yet sent") straight away, on the same tap, not at the next launch. It is not lost, and it goes automatically the next time the app is allowed to send.

The same is true when you simply have no signal. Adding a client on a phone in Airplane Mode, or out of coverage, does not lose the client: the app tells you it is "held on this phone and will be sent next time it connects", counts it in the yellow bar, and sends it on a later launch. The app never says a server refused something when there was no server to ask.

And the same is true when TechieCRM itself answers with an error. If the workspace is busy, being restarted, or refuses the record for a reason of its own, the app says "Your workspace couldn't take just now (server said 503). is held on this phone and TechieCRM will try again.": it quotes the number the server really sent, keeps the record on the phone, counts it in the yellow bar, and retries it every time you open the app. It never claims you were offline when a server did answer, and it never claims a server answered when none was asked.

Nothing you have entered is ever thrown away automatically. If the server refuses one of your held changes (a record it will not accept for some reason of its own), that change stays held and is tried again every time the app opens, and the other changes queued behind it still go. There is no rule anywhere in the app that discards your work after so many tries or so many days.

And what you typed keeps showing on screen while it is held. A routine background sync can land while a change is still waiting to be sent: for example, you edit a ticket's subject with no signal, then walk back into coverage and the app quietly refreshes the list before your edit has gone out. The record still shows what you typed, not the workspace's older copy, until your change actually reaches the server. Fields nobody else changed keep updating from the sync as normal; only the one(s) you edited are protected. Nothing here changes what is actually SENT; the held change still wins on the server the moment it flushes. This only stops the phone's own screen from looking, for a moment, like your work had vanished.

⚠ The one thing this cannot do yet is show you the held changes. The yellow bar counts them and the app sends them, but there is no screen listing them, so you cannot open, edit or discard one until it goes. That screen comes after this release.

What to do about it

The explanation screen tells you, in this order:

TechieCRM's reason, in its own words, boxed and labelled so you can see it came from the server and not from the app.
A download link, if there is one. Today there usually is not (there is no App Store or TestFlight build of the mobile app yet), so the app does not show a button that leads nowhere.
A "Contact TechieCRM support" button (from version 0.8.0.2), which opens TechieCRM's support page, www.techiecrm.com/support/, the same page the desktop points to. It is always there when something is blocked, so there is somewhere to go even when there is no download link. The same link appears under an access-withdrawn notice and under a refused sign-in message, beneath the server's own words.
The line that actually works: Reinstall from your Mac: ./bin/install-iphone.sh. Connect the iPhone to the Mac TechieCRM was built on, unlock the phone, and run that script. It installs the current build.

That line is on every explanation screen, including the "hasn't been confirmed yet" one, but on that screen it is headed "If this bar is still here in a few days" and says plainly that there is nothing to do right now. Nothing is blocked on a new install, so nothing needs reinstalling.

If the app can't reach TechieCRM

Being offline is not the same thing, and the app does not pretend it is.

Short outages change nothing. The app remembers the last answer it got and keeps working normally on it.
After 14 days with no successful contact, the app can no longer confirm this build and goes read-only in the same way: you cannot add or change anything until it checks in, but every record already on the phone stays readable. It says so in its own words: "TechieCRM hasn't reached the server in N days". It has not expired; it simply cannot be confirmed. One successful connection clears it immediately.
If your phone's date and time are wrong, that can look identical to being offline for weeks. When the app can tell that is what happened, it says so and points you at Settings ▸ General ▸ Date & Time rather than blaming your signal.
A brand-new install that has never reached TechieCRM shows "TechieCRM hasn't been able to confirm this build yet.": a yellow bar, but not a block. You can read, search and add records exactly as usual, and the app keeps downloading your records, so you are not looking at an empty app. The bar disappears by itself the moment the app gets through to the server. Tap it and it explains itself, including the one limit: if it still has not been confirmed 14 days after the app was installed, the app goes read-only until it does. That is the same 14 days described above, counted from the install rather than from the last successful contact. Changing the phone's date does not extend it: an install date later than "now" is read as now.
A wrong clock cannot lock you out permanently. Winding the phone's date back (or a phone whose battery went flat and comes up believing it is 1970) used to make the app decide the install was decades old and go read-only for good, with no way back but a reinstall. The app now remembers when it was actually installed and will not read that moment as any older than it is, so putting the date back to automatic gives you your app back on the next launch. It is not a way to get unlimited extra time; the 14 days still run from the install. One narrow exception is accepted deliberately: a phone whose clock was running ahead when the app was first installed can get one further 14-day window once the real date catches up to that moment. Closing it would mean risking a permanent false lock-out on an honest phone that is simply offline, and that is the worse mistake of the two.

If a newer build is available

If TechieCRM has a newer build in your channel, you get a green bar you can dismiss, not a block. The app keeps working exactly as before. You are being told, not stopped.

What the iPhone and iPad app tells TechieCRM, and where it connects

iPhone or iPad. At each check-in the app tells TechieCRM whether it is running on an iPhone (a phone, registered to the person who signs in on it, one per person) or an iPad (a shared tablet, not registered to anyone and not counted). See Your phone is registered to you under Signing in.
Following a server move. Each check-in also tells the app where TechieCRM's sync service lives. If TechieCRM moves it, the app follows on the next check-in, with no app update; the check-in itself always goes to the address built into the app. The app only follows a secure (https) address on techiecrm.com; it ignores any other address and keeps using the built-in one.

On Android phones and tablets

Android builds that include the check-in update behave as described in this section: the same yellow bar with TechieCRM's own words, the same explanation (opening by itself once when the build is blocked or has gone 14 days unconfirmed, and on a tap otherwise), the same 14-day rule counted the same way, the same blue bar for a newer build, and the same rule that records already on the device stay readable in every case. The phone also learns your plan at each check-in, so modules your plan does not include are locked in the module menu with a 🔒, a module still in beta testing shows a green "B" (dimmed for non-testers, who get the beta message instead of the module), and on a read-and-delete plan the Add buttons are hidden. Android builds made before this update did none of this: they never checked whether the build was still allowed to run.

The differences on Android:

Which build am I on? Open Settings; the Version line reads the version and the channel, for example 0.8.0.5 · beta. The sign-in screen shows the same at the bottom (Beta 0.8.0.5).
Android is a Beta build from version 0.8.0.5. It is allowed to run through the Beta programme, which ends on 31 January 2027 (extended from 15 November 2026); from 1 February (judged in UTC, so on the evening of 31 January in North American time zones) TechieCRM moves to its general release and a Beta build shows "This build has expired" with TechieCRM's reason ("This is a Beta build. TechieCRM has moved to General release, and Beta builds no longer run. Download the current stable release to continue.") and becomes read-only until a newer build is installed. The Android app has no date of its own built in: the end date comes from TechieCRM at each check-in.
Phone or tablet. At each check-in the app tells TechieCRM whether it is running on a phone or a tablet (a tablet is any device whose shorter screen side is at least 600 dp, so turning it sideways does not change the answer). A phone is a personal device registered to the person who signs in on it (one per person); a tablet is shared and is not counted. See Your phone is registered to you under Signing in.
The way back. The explanation reads Reinstall from your computer: ./gradlew installDebug: connect the device to the computer TechieCRM was built on, with USB debugging turned on, and run that command in the TechieCRM_mobile_android folder. There is no Google Play build yet.
Wrong date and time. The app points you at Settings ▸ System ▸ Date & time (the exact menu names vary a little between phone makers).
Nothing to send. The Android app cannot change records yet, so there is never a "change not yet sent" line on the yellow bar.
When the block lifts. The Android app checks in again every time you return to it while the build is not confirmed, so a block that TechieCRM lifts clears without closing the app.

← Quotas & Messages

Meeting Notes: the AI note taker →

Signing in

Your phone is registered to you (a tablet is shared)

Light and dark

Moving around: there are no menu buttons

Filtering a list by record type

Working a list

Clients on a full-width iPad

Working a record

Key Fields: choosing which fields a record shows

What each section shows, and when it loads

A client on the phone

Adding a client from the phone

Changing a client from the phone

A sale on the phone

Closing a sale on the phone

A ticket on the phone

A campaign on the phone

Client Status on the phone

The To-Do list on the phone

Calendar: Day view

Agenda: the start of your day

Dashboards

The operations modules

Projects

Inventory

Work Orders

Financials

Partners

Agreements

Compliance & SLA

HR & Payroll

Quotas

Order Desk: retired into Financials

Messages

Email

Your mail accounts on your phone

Library / Knowledge Base

Personal

What each module can show you today

On Android phones and tablets

A note on the holds

Data on the phone (how sync will work)

What each module keeps on the phone

If the phone has been offline for a very long time (added 2026-09-06)

Times always show in your phone's timezone

If this device is reported lost or stolen (remote wipe)

On Android phones and tablets

When the app says this build can't be used

What you will see

What still works

What stops

What to do about it

If the app can't reach TechieCRM

If a newer build is available

What the iPhone and iPad app tells TechieCRM, and where it connects

On Android phones and tablets