Talk to AnnaMost contact-sharing tools assume your whole company lives in one ecosystem. Reality is messier. A typical setup we see: the company runs Google Workspace, but the outsourced sales team, the accounting firm, or a recently acquired subsidiary lives in Microsoft 365 and Outlook. Both sides need the same customer list — current, in their own address book, on their own phones.
Neither Google nor Microsoft can do this natively. And the established contact-sharing tools in this space work only inside Google: a Google label shared with other Google users. The moment one recipient is on Outlook, you are back to emailing CSV files.
Rolyio was built around exactly this gap: a label owner can be in Google and recipients in Outlook, or the other way around. Here is the scenario end to end.
The scenario
Acme runs Google Workspace. Their sales operations manager maintains a “Customers” label in Google Contacts — 400 contacts, updated daily. Acme also works with an external sales agency whose ten people are on Microsoft 365. The agency needs the customer list in Outlook: in email autocomplete, in the Outlook mobile app, on their phones when a customer calls.
The old answer was a weekly CSV export, which meant the agency was always up to a week behind, duplicates piled up on every import, and when the engagement ended there was no way to take the data back.
How it works with Rolyio
One label, two ecosystems
The manager connects their Google account at app.rolyio.com; the agency users connect their Microsoft accounts. Rolyio speaks both languages natively:
- On the Google side, a label is a real Google contact group — the same thing you see in contacts.google.com.
- On the Microsoft side, the equivalent is an Outlook category: Rolyio uses master categories plus the category assignments on each contact.
Rolyio does not introduce a third place where contacts live. Contacts stay in each provider; Rolyio stores the sharing relationships, the roles, and enough state to run sync correctly. (There is one deliberate exception: snapshots of deleted shared contacts are kept in Trash for 30 days so mistakes are recoverable.)
Sharing across the boundary
The manager opens the “Customers” label, chooses Manage access, and adds the ten agency addresses with the View role. Recipients who have already connected an account go active immediately; anyone who has not yet signed in shows as pending and completes automatically after their first login — no coordination required.
On the next sync, each agency user finds a “Customers (Shared)” category in Outlook, containing all 400 contacts. Because the category is a native Outlook construct, the contacts show up everywhere Outlook contacts do: desktop, web, and the mobile address book.
What each role means across ecosystems
Roles behave identically regardless of which side of the fence a user is on:
- View — the recipient gets the contacts; if they edit one locally, the owner’s version wins on the next sync.
- Edit — the recipient can add contacts to their “(Shared)” category, and those flow back into the owner’s Google label. Their edits to existing contacts sync back too.
- Can reshare — the recipient can grant access onward, e.g., an agency lead adding a new hire.
So an Outlook user with Edit rights can add a contact in Outlook, and it lands in the owner’s Google contact group. The full matrix is documented in roles and permissions.
Sync mechanics: two providers, two rhythms
The two ecosystems give us different tools, and Rolyio uses the best available on each side:
- Microsoft supports change notifications via Graph webhooks, so changes on the Outlook side reach Rolyio in near real time.
- Google offers no push mechanism for contacts, so Rolyio polls roughly every 60 seconds using incremental sync tokens. There is also a manual Sync button when you want a change through right now.
Between accounts, only shared data moves — Rolyio never touches contacts outside shared labels. Conflicts are resolved last-write-wins with role awareness, and deduplication is by email address: if an agency user already had a customer saved in Outlook, sharing does not create a duplicate.
One honest limitation
Microsoft Graph does not allow renaming a category. So if the owner renames the label on the Google side, the change cannot be applied in place to the Outlook category the same way it would be for a Google recipient. It is a platform constraint worth knowing about, not a data-loss risk.
The reverse direction works too
Everything above runs the same way flipped: a Microsoft 365 company can own the label (as an Outlook category) and share it with Google Workspace or Gmail recipients, who receive it as a “(Shared)” Google contact group. Mixed teams — some recipients on Google, some on Microsoft, on the same label — are the normal case, not a special one.
When the engagement ends
This is where cross-ecosystem sharing pays off most. When Acme’s contract with the agency ends, the manager removes the agency from the label’s access list. On the next sync, the shared contacts are removed from the agency users’ Outlook address books. Compare that with the CSV era, where the data was simply gone — permanently, into someone else’s mailbox.
Setting it up
The whole flow takes a few minutes: connect an account on each side, invite your team, open a label, and share it. If your organization is split across Google and Microsoft — or works with partners who are — this is the difference between “everyone has some version of the list” and “everyone has the list.”