Retrieve available contact photos when email sync creates People

[AlexyBouvet]

Scope & Context

Could Twenty optionally retrieve an available contact photo from the connected email provider when email sync creates a Person, and populate the native Person avatar? This would make automatically created contacts easier to recognize without a separate manual photo import. Calendar sync could reuse the same mechanism where appropriate.

The request is to retrieve the provider photo URL or image when available, then make it usable by Twenty. It does not assume that every email sender has a retrievable photo.

Current behavior

In the code inspected at commit 0546203, the contact creation input only contains handle and displayName. formatPeopleToCreateFromContacts maps these to email, name, companyId and createdBy, without photo information. This is a source observation, not a claim about the exact revision deployed to every Cloud workspace.

Contact type

Person creation mapping

Expected behavior

When a connected provider exposes a photo for an unambiguously matched contact, Twenty should populate the native avatar and display it in the People table and Person detail page. A missing photo, insufficient permission or provider error should leave the contact intact with the existing fallback. An existing user supplied or imported avatar should not be overwritten automatically.

An optional backfill for existing contacts without avatars would also be useful. Repeated syncs should not create duplicate files or repeatedly download an unchanged image.

Technical inputs

A possible implementation is a separate asynchronous photo enrichment job after contact creation. Resolve the provider contact by an exact email match or stable provider resource ID, never by display name alone. Skip ambiguous matches. Keep mail ingestion independent of photo lookup latency and use bounded concurrency, caching and retry backoff for provider limits.

For Google, the People API exposes photos through people.connections.list, and otherContacts.list supports emailAddresses and photos in readMask. The latter covers contacts typically accumulated from interactions and requires contacts.other.readonly. Saved contacts use their applicable People API scopes. These are potential lookup sources, not a universal photo lookup for arbitrary sender addresses; additional OAuth consent may be necessary.

Google Other contacts

Google saved contacts

For Microsoft, Graph exposes contact photo content, for example GET /me/contacts/{id}/photo/$value, subject to Contacts.Read permissions. Directory user photos have separate permission and availability constraints. Neither route guarantees a photo for an arbitrary external sender.

Microsoft Graph photo API

Rather than persisting an expiring or authenticated provider URL as the displayed avatar, download and validate the available image through the supported file lifecycle and attach it to Person.avatarFile. Preserve provenance separately if useful, without exposing tokens or signed URLs. Bound file size, validate image content and redirects, reject default placeholder photos where the provider identifies them, and never replace a valid avatar with a failed response. Recheck that the Person still exists and has no avatar immediately before attaching the file, so a concurrent merge or manual edit is respected.

Acceptance would be an actual provider contact with an available photo appearing in both the People table and Person page after sync, including after reload. Missing photos and denied permissions should not fail contact creation; manual photos must remain unchanged; replay should produce no duplicate files. An email sync scope alone must not be assumed to grant access to contact photos.

Would this fit the native sync roadmap, or is there an existing extension point you would recommend for implementing it without duplicating provider authentication and file handling?

[BOHEUS]

@neo773