#Outlook/Teams/Gmail40 debatiendo

Based on the symptoms, I would first look at the email itself rather than Salesforce configuration.

The interesting part is that:

* The same Contacts match correctly on another email in the same thread

* All users are seeing the same behavior

* The issue happens only for one specific message

That usually points toward something different in the email metadata/header information.

A few things I would check:

1. Compare the working email and failing email headers:

* From address

* Reply-To address

* To/Cc values

* Message identifiers

Sometimes two emails can look identical in Outlook but have different underlying header information that Salesforce uses for Contact matching.

2. Check how the failing email was generated:

* Was it forwarded?

* Sent through a shared mailbox?

* Routed through another system?

* Generated by a distribution list or automation?

3. If the email has been logged in Salesforce, compare the EmailMessage details:

* FromAddress

* ToAddress

* CcAddress

* Headers

* ThreadIdentifier

Since the issue follows the message and not the user, permissions, cache, or user settings would be lower on my troubleshooting list.

My first suspicion would be that Salesforce is not able to correctly extract the external participants from that specific email because of something different in the message headers.

@Andreas Rosen

The short answer: yes, Lightning Sync will keep running past October 2026 and up to April 2027, but only if you take a specific admin action first. It won't keep running automatically.

Microsoft's new plan isn't a single hard cutoff. It's a phased, admin-controllable disablement that begins October 1, 2026 and concludes with permanent shutdown on April 1, 2027. The critical part is what happens by default at the October date. Beginning October 1, 2026, EWS is blocked unless the tenant configures an AppID Allow List and sets EWSEnabled=True. Without admin action, Microsoft sets EWSEnabled=False and EWS apps stop working. 

So for Lightning Sync specifically, this means: if you do nothing, your sync likely breaks in October 2026, not April 2027. To get the full runway to April 2027 that you're hoping for, your Exchange admin needs to add the Salesforce EWS app to an AppID Allow List and set EWSEnabled=True. Microsoft recommends doing this before the end of August 2026, because tenants that complete it before the deadline are excluded from the automatic October 1st blocking. After April 1, 2027 there are no exceptions and no extensions. 

On the Salesforce side, the position is consistent with this. Salesforce confirms that Lightning Sync configurations using EWS won't capture or sync data after EWS is retired, and recommends either migrating the Microsoft connection to Microsoft Graph or moving from Lightning Sync to Einstein Activity Capture. Worth knowing that the Graph connection for the Microsoft side is still relatively new, so test it rather than assuming a clean swap. 

So to directly answer your planning question: yes, you can buy yourself the time to April 2027 to move to a new solution with proper concept and care, which is exactly the sensible approach. But that extra time is not automatic. The action item is to have your Exchange admin set up the AppID Allow List with EWSEnabled=True before end of August 2026. Miss that, and your bridge collapses in October 2026 instead.

One thing I'd flag for your migration planning, since you mentioned wanting to move with proper concept. If your end goal is Einstein Activity Capture, be aware of a key behavioral difference. Lightning Sync syncs contacts and calendar events. EAC covers events and contacts too, but it does not support shared calendars, resource calendars, or delegated calendars. If any of your users rely on shared or room calendars flowing into Salesforce today, that's a gap you'll want to design around before committing, rather than discovering it mid-migration. Better to surface that now while you have the runway. 

-SP

Hi, If the user has already setup OOO using chatter and user go on vacation then it can be monitored. Build a schedule flow, that will run at 1 am (or anytime) daily. It'll pull the users of the support team. It'll now use Get Records element to get the object OutOfOffice with a filter where userid equal to triggering record userid. Lets say there are 5 users in support team and one is ooo then 1 record will be pulled from Get Records element. In this way flow will know that user is ooo, now Update Records element can be used that will reassign the case to another user who is available. Basic view of flow is attached

https://trailhead.salesforce.com/trailblazer-community/feed/0D54S00000MjKvoSAFAnother solution suggested below

https://sforcemaximizer.com/how-to-reassign-tasks-when-the-task-owner-is-out-of-the-office-with-automation-in-salesforce/

This is a very common gotcha — the default login screen in the Outlook integration shows username/password, but SSO is there, it's just hidden behind the Custom Domain step. Here's exactly what your users need to do:

1. Open Outlook and click the Salesforce icon in the sidebar or ribbon to open the Salesforce panel
2. On the login screen, look at the bottom and click "Use Custom Domain"
3. In the field that appears, type your org's My Domain name — just the subdomain, not the full URL (e.g. if your login URL is yourcompany.my.salesforce.com, enter yourcompany)
4. Click Continue
5. The screen will now show your SSO login button (usually labeled with your company name or identity provider, e.g. "Log in with Microsoft" or "Log in with Okta")
6. Click that button and authenticate through your normal SSO flow

Once they've done this once, Outlook should remember the custom domain for future logins.

If the SSO button still doesn't appear after entering the custom domain, check two things in Salesforce Setup:

• My Domain → confirm "Deploy to Users" has been clicked (not just enabled)
• My Domain → Authentication Configuration → make sure your SSO provider is checked under "Authentication Services" — if it's unchecked, users won't see the SSO option even with the right domain entered

Hope that gets them sorted!

@Neil Shafer-Ross

Three different products often get confused here, so let me separate them clearly because that's the whole answer.

You're correct that they are separate tools. Here's the breakdown.

Outlook Integration (formerly Lightning for Outlook) is the side panel that lives inside Outlook and lets reps log emails and view and create Salesforce records from their inbox. This is the tool your org wants everyone to use, and it is not being retired. Salesforce actively recommends the Outlook Integration, alongside Einstein Activity Capture, as the next-generation replacement product, and continues to introduce enhancements for it every release. So training your team on it is a safe investment, not wasted effort. 

Salesforce for Outlook is the old desktop plugin, completely different from the Outlook Integration despite the similar name. This is the product retiring in December 2027, rescheduled from its earlier June 2024 date. If your org is on the modern Outlook Integration, this retirement does not affect you. I suspect the "end of 2027" date you heard is this product, and it's getting conflated with the tool you actually want to roll out. 

Lightning Sync is the third tool, and it's a background sync engine for contacts and events between Outlook and Salesforce. It's separate again from both of the above. It's also on its way out. Salesforce stopped offering Lightning Sync to new customers back in the Winter '21 release, and its real death blow is coming from Microsoft's side, not Salesforce's. 

So, to directly answer your question: yes, roll out Outlook Integration with confidence. It is the recommended, actively maintained tool, and it is not being retired. The 2027 retirement applies to the old Salesforce for Outlook plugin, which is a different product. Train your users without worrying about that date.  

-SP

Hi Tony, 

Great question! Here's what you need to know about using alternate email addresses with the Salesforce App for MS Teams: 

Short answer: The Salesforce App for MS Teams uses the email address tied to your Microsoft/Teams identity (i.e., your Outlook/M365 login) when creating meeting invites and Teams chats — it does not natively allow you to swap in a different "from" email address like your SF business email. 

However, here are your options: 

1. Map the correct email in Salesforce User settings: 

Make sure each Salesforce user's Email field matches their Outlook/M365 email (

). The Teams app uses this mapping to link identities. If the emails don't match, it can cause issues with record association and invite creation. 

2. Use Microsoft 365 email aliases: 

If your org uses M365, you can add

as an email alias on the user's M365 account. This way, both email formats are associated with the same mailbox, and Teams meeting invites will still work correctly regardless of which format is used. 

3. Salesforce Inbox / Einstein Activity Capture: 

If you're using Salesforce Inbox or Einstein Activity Capture alongside the Teams integration, you can configure which email address is used for activity logging. This won't change the Teams meeting invite sender, but it helps ensure activities are captured against the right Salesforce records. 

4. Custom workaround via Flow + Teams Connector: 

For full control over meeting invites with a specific email, some teams use a Salesforce Flow + Microsoft Power Automate (Teams connector) approach to generate Teams meeting links programmatically and send them from the desired email address. 

My recommendation: Start with Option 2 (M365 alias) as it's the simplest and doesn't require any Salesforce config changes. Hope this helps!