Our sales team receives client calls on their work phones, but the devices usually display only unknown numbers. Our contact data lives mainly in Business Central, with some records in Dataverse, and Outlook Mobile does not automatically sync those contacts into the phones' native address books.
As a result, employees either miss or ignore client calls, or manually save business contacts to their personal devices, which creates privacy and data-management concerns. We previously tried using Power Automate to sync the records, but the flow repeatedly hit API limits and created duplicate contacts, so we had to disable it.
What reliable approach are you using to make centralized Microsoft 365 or CRM contacts appear in the native mobile caller ID without requiring sales reps to open a CRM app while the phone is ringing?
4 Answers
The duplicate and throttling problems are fixable if you keep the sync state correctly. Store the Business Central or Dataverse record ID on the Outlook contact as a stable identifier, rather than matching on names or email addresses. For API usage, use Dataverse change tracking and delta tokens so each run retrieves only records changed since the previous sync.
It also helps to create a dedicated contacts folder for each user through Graph instead of writing into their default contacts. That folder can be rebuilt or removed without affecting contacts employees added themselves. Outlook Mobile can then sync that account’s contacts to the native address book, which is what enables caller ID on the lock screen.
Business Central is the more difficult part because it uses a separate API. Mirroring the required BC records into Dataverse first would allow the rest of the process to use one pipeline, although it does add another system to maintain.
The cleanest long-term setup is usually a CRM integrated directly with the phone system or Microsoft 365. That lets the telephony platform perform the caller lookup instead of trying to copy every CRM record into each employee’s personal address book.
An internal mobile portal can provide fast CRM caller lookup without copying contacts into employees’ personal address books, and it can include auditing and direct database connections. However, that only solves the problem if the phone system itself can identify the caller; asking someone to search an app while answering a ringing phone is not a true native caller-ID solution.
A custom synchronization service is more dependable than a basic Power Automate flow. A database-backed process using Microsoft Graph can track contacts, handle updates, and avoid repeatedly downloading the entire dataset. Microsoft’s contact model is complicated because it includes several older systems, so a proper sync layer helps keep it manageable.
That makes sense, but I was hoping to avoid maintaining custom infrastructure just for contact syncing. I may need to compare a lightweight third-party tool with building a Graph-based service.
The GUID matching, delta tokens, dedicated folders, and BC-to-Dataverse mirroring sound technically solid, but together they feel like a full custom product just to provide caller ID. I’m concerned about the ongoing maintenance when Graph endpoints or authentication tokens change.