Zodiac Tech CRM Docs

Permissions

Every permission the Android app asks for, why it needs it, and exactly what changes if you deny it.

sales admin Easy ⏱ 5 min Updated 2026-10-05

Permissions

There is no "grant everything and hope" here. This page lists every permission the app declares, what it is for, and the honest consequence of denying it. The app is designed to stay usable when permissions are missing — it just does less.

Who this is for

  • Sales agents who saw a permission prompt and want to know what it means.
  • Admins setting up phones for a team.

Difficulty: Easy · Time: about 5 minutes · Prerequisites: the app installed and a login — see Installation.

The permissions, and why

Permission Asked when Why If you deny
Phone state (READ_PHONE_STATE) First call feature use, or Device health → ALLOW Know call state and enumerate active SIMs (used for the monitored-SIMs setting) SIM count shows as unknown; all SIMs are treated as monitored
Call log (READ_CALL_LOG) Same prompt Read the device call log so calls are matched to leads and logged to the CRM automatically Call tracking stays off ("Permission needed" in Device health); you can still log calls manually from the lead
Phone numbers (READ_PHONE_NUMBERS) Same prompt Declared alongside phone state to help identify the SIM/phone number No call-log sync benefit parsing; harmless
Notifications (POST_NOTIFICATIONS, Android 13+) First launch, and when push is set up Show push alerts and sync-status notifications Push arrives silently or not at all; in-app notifications still work
Battery optimization exemption (REQUEST_IGNORE_BATTERY_OPTIMIZATIONS) Only when you tap ALLOW UNRESTRICTED in Device health Stop Android's Doze mode from delaying background sync and recording discovery Background uploads may be delayed until the phone next wakes
Audio settings (MODIFY_AUDIO_SETTINGS) No prompt (normal permission) Mute / speakerphone on the optional in-app call screen n/a — granted at install
Answer phone calls (ANSWER_PHONE_CALLS) No prompt until call features "End call" best-effort from the in-app call screen; on modern Android the OS only lets the default dialer end calls, so this is wrapped and only used when the role is held The call screen tells you to end the call yourself
Call phone (CALL_PHONE) Only when the app holds the default-dialer role Place calls via the system telecom stack when LeadHub is your Phone app; without the role the declaration is inert Calls open the normal dialer prefilled instead
Internet / network state No prompt (normal permissions) Talk to the CRM n/a

The one permission that matters most READ_CALL_LOG is what turns the app from a manual CRM into an automatic call logger. Everything else has a graceful fallback. See Calling from the CRM for what sync does with it.

Step 1 — Grant the call permissions

  1. As soon as you use call features (or open Device health and tap ALLOW on the call-tracking row) Android shows the runtime prompt for Phone state, Call log and Phone numbers.
  2. Tap Allow.
  3. Device health refreshes: Call tracking switches to the green tick with "Call-log permission granted — calls sync from the device call log."

Step 2 — Review everything later

  1. Open More → Device health.
  2. Read the Health check rows — each row shows a state and, where a fix exists, a button:
    • Call tracking → ALLOW re-requests the call permissions.
    • Notifications → ALLOW (Android 13+) or SETTINGS.
    • Push notifications (FCM) → ALLOW / SETTINGS / RETRY depending on its state.
    • Battery optimization → ALLOW UNRESTRICTED opens the system dialog.
    • CRM Phone (default dialer) → REQUEST / RELEASE.
  3. Tap RE-CHECK DEVICE after changing anything.

Do not disable permissions "to be safe" on a work phone Denying call-log access is a valid privacy choice, but it silently turns off automatic call logging for that phone — the CRM will not receive calls from it. If a device must not sync calls at all, use Settings → Excluded numbers or do not install the app rather than leaving a half-permission state.

Expected result

  • Device health shows green rows for the permissions you granted, and honest warnings for the ones you did not.
  • The CRM receives a capability snapshot each time you open Device health (and at least daily in the background) so admins can see what each device supports — see Device health.

Common mistakes

Mistake What happens Fix
Granting call permissions but skipping battery exemption Calls sync, but hours late when the phone is idle Tap ALLOW UNRESTRICTED in Device health
Denying notifications, then wondering about missed alerts Push is disabled at the OS level Device health → Notifications → ALLOW / SETTINGS
Looking for permissions in the app menu first They live with Android, not the app Device health buttons deep-link into the exact Android screens

Troubleshooting

  • Permission prompt never appears again after denials — Android suppresses repeat prompts. Device health's SETTINGS buttons open the right system screen so you can grant it there.
  • "Call tracking" still red after granting — tap RE-CHECK DEVICE; if it stays red, the ROM may be blocking call-log reads (some OEM builds do). The app reports this rather than pretending.
  • Battery "Allow unrestricted" button does nothing — the system dialog may be unavailable on some ROMs; follow the fallback text (Settings → Battery).

Technical details

  • Declared in android/app/src/main/AndroidManifest.xml; runtime checks and explanations come from com.leadhub.sales.capability.CallCapabilityEngine.
  • Call tracking is FULL when READ_CALL_LOG is granted and LIMITED when it is not — "UNAVAILABLE" is never claimed because Android provides no supported API for "permanently blocked".
  • The capability snapshot (including call_log_permission, phone_state_permission, notification_permission, battery_optimization_ignored and the reasons list) is posted to POST /api/v1/mobile/devices/capabilities and stored in device_capability_snapshots.

Was this page helpful?