Data security and device pairing: the installed app is not a key to anything
A clinic's calling app handles some of its most sensitive data: patient phone numbers, notes on fertility or cosmetic procedures, and recordings of real conversations. It also runs on phones that get lost, handed over between staff, and sometimes belong to the telecaller personally.
AtomCRM's calling app is designed on one assumption: anything shipped inside the app is public. Anyone can unpack an Android app file and read what is inside in seconds. So the app ships with nothing worth stealing, and access comes only from a person's own sign-in.
- Signing in pairs the handset: AtomCRM issues a key for this one phone, this one person and this one clinic workspace.
- The installed app contains no master key, storage password or messaging secret.
- Credentials are stored in the Android Keystore, never in a plain file or a log.
- One handset holds one live credential; a new sign-in replaces the old key.
- Any device can be revoked from the CRM, and an administrator's block survives a fresh sign-in.
Sign in and pair the phone in one step
There are no activation codes to hand out and no shared key built into the app. A telecaller signs in with the email and password they already use in AtomCRM. Behind that one button, the app exchanges the password for a session and immediately asks the CRM to issue a key scoped to this handset, this person and this workspace.
If the pairing fails, the sign-in fails with it. That is deliberate: a phone that looks signed in but cannot upload is the worst possible state, because it would lose a whole day of calls and recordings without anyone noticing.
A phone blocked by an administrator is told so at sign-in, in words, rather than failing quietly later.
Why per-device pairing beats a shared key
A common shortcut in workforce apps is one key inside the app that every installation shares. Here is the difference.
| Question | A shared key in the app | AtomCRM per-device pairing |
|---|---|---|
| Secret inside the app file | Yes, and it is the master key | None |
| Damage if someone extracts it | Every workspace | One handset, and the key never ships in the app |
| How to revoke | Only by rotating the whole deployment | One device, from the CRM |
| Who a call belongs to | Whatever the app claims | The person who paired the phone |
| Needs a password to obtain | No | Yes |
The last two rows matter beyond security. Software on a phone should not get to decide who made a call. Pairing closes the attribution gap and the security gap with the same mechanism.
The security rules the calling app follows
- No secret in the build. No app key, storage credential or messaging secret. Recordings upload through short-lived links the server issues per file, so the app never holds a storage password.
- Android Keystore. Credentials live in the Keystore, hardware-backed where the phone supports it. Never in a plain file, a log line or a crash report.
- One workspace per key. A stolen handset cannot reach another clinic's data, and a key presented with a different workspace is refused.
- Re-pairing replaces the key. One handset holds exactly one live credential. When a colleague signs in on the same phone, the previous person's key stops working, so they cannot keep posting calls from a phone they handed over.
- Blocks survive sign-in. An administrator's block is not undone by whoever holds the phone tapping Sign in again.
- HTTPS only. No debug switch that could survive into a release build. Release builds are minified and not debuggable.
- Rate limits per device, not per office. Fifty phones on one clinic Wi-Fi are not punished together, and one misbehaving phone cannot use up another's allowance.
Privacy for telecallers using their own phone
Plenty of clinics run calling on phones that are also personal phones. Three properties are worth stating plainly to the people carrying them.
Nothing from before the install
The first run marks the newest call on the phone and sends none of the history behind it. A separate rule refuses anything older than twelve hours.
Sign out means stop
Signing out unpairs the handset, and the app cannot upload anything until someone signs in again. The screen says so.
The app records nothing
It collects files the phone's own recorder already wrote. That recorder is a setting the phone's owner can see and switch off.
Where AtomCRM fits in your DPDP Act compliance
On the CRM side, AtomCRM captures consent at lead entry, uses role-based access so reception, doctors and billing each see only what they need, and logs who viewed or exported a record. ICG signs a data processing agreement with every clinic client, which your own compliance with the Digital Personal Data Protection Act 2023 needs.
Software is only part of it. Your clinic still decides who gets AtomCRM access, how long recordings are kept, and what happens when a telecaller leaves. Revoke their device the day they go, reassign their leads, and review access for anyone who changes role.
What AtomCRM costs
₹50,000/- one-time setup
+ ₹799/- per telecaller per month
The calling app is included for every telecaller. Calls go over the SIMs your team already uses, so there is no IVR to rent. The only added running cost is storage for the call recordings you choose to keep.
AtomCRM is live at 80+ healthcare centres in India, including 15+ IVF centres, 20+ aesthetic centres and 10+ eye centres.
Security and pairing: common questions
What happens if a telecaller loses their phone?
An administrator revokes that device in AtomCRM. The key on the lost phone stops working, and the telecaller signs in on a new handset, which pairs it with a fresh key.
Can someone use a copy of the app to get into our data?
No. The installed app contains only the address of the service, which is not a secret. Access needs a real AtomCRM user's email and password, and each key is scoped to one workspace.
Can two telecallers share one phone?
They can take turns, but a phone holds only one live credential. When the second person signs in, the first person's key stops working, so calls are always attributed to whoever is holding the phone.
Does ICG sign a data processing agreement?
Yes. ICG signs a data processing agreement with every clinic client using AtomCRM.
Does the calling app upload a telecaller's personal calls?
It uploads nothing from before it was installed and nothing older than twelve hours, and it stops uploading entirely once the telecaller signs out.
Keep reading
AtomCRM overview
The calling app, the CRM behind it, the Android recording constraint and pricing on one page.
Automatic call capture
How AtomCRM reads every call from the handset's own log, including calls dialled outside the app.
Call recordings on the right lead
The honest version of Android call recording: the phone records, the app collects, and matching is by time, never by file name.
Migrating to AtomCRM
Moving from spreadsheets or a legacy CRM: data clean-up, stage mapping, recordings, a short overlap and cut-over.
See the AtomCRM calling app on your own handsets
We start with a two- or three-phone pilot, so you know exactly what you are buying before your whole calling team moves over.
