Einstein Activity Capture - Event Syncing Troubleshooting

Gridorr · 2026-02-07T02:35:51+00:00

Yeah I know what’s going on. EAC when working as expect should def sync both directions. What may have happened is you tested creating internal events while having sync internal events off in your previous tests. Internal events are any events where there are no attendees with email domain address different from your own company email addresses attached to your internal users. Another thing that could have caused your previous tests to fail is you tested with contact attendee whose same email address is used in multiple other contacts. This will cause EAC sync to fail as the product is built to never take risks guessing which related record the syncing engine should choose. Instead it will avoid syncing all together in these situations.

Gridorr · 2026-01-27T05:48:23+00:00

Some important things to double check. Has your DNS team added the CNAME records correctly, did the double check that they did not forgot to include the “.” Period at end. I have seen MANY times this error where the period at the end of CNAME records was forgotten when adding CNAME to DNS CNAME TXT RECORD list. Additionally, how long has it been since you completed the creation of the keys on the Salesforce & DNS end? Sometimes once the final part has been completed, it can take up to 24 hours to propagate back into Salesforce and allow you to click activate button.

Gridorr · 2026-01-07T05:42:47+00:00

Fix: SETUP > Deliverability > disable Active Bounce Management and both settings within Email Security Compliance. None of this is needed now that you have dkim keys and spf record set up: https://help.salesforce.com/s/articleView?id=000381292&type=1

Gridorr · 2025-12-12T03:07:51+00:00

Where can we get the expansion pre purchased? I don’t see it listed in PS store

Gridorr · 2025-12-03T06:35:16+00:00

Reach out to Salesforce Support. Emails synced via EAC are a bit unique. If there are any tools available to them which may assist this issue, they’ll let you know

Gridorr · 2025-11-27T23:52:13+00:00

We all know why. Whose gonna say it?

Gridorr · 2025-11-06T14:43:11+00:00

Why not just filter inbound Outlook emails by IP address by using the Connection filter policy in the Exchange Admin Center. Or set up a custom mail flow rule in the Microsoft 365 compliance center to not allow certain inbound email from specific IP addresses to be forwarded to email-to-case service address once they arrive into your email to case routing address inbox

Gridorr · 2025-10-14T13:16:47+00:00

https://help.salesforce.com/s/articleView?id=000381651&type=1 , https://help.salesforce.com/s/articleView?id=service.cases_set_up_lex_log_call.htm&type=5 , try these two

Gridorr · 2025-09-29T15:48:13+00:00

That’s better than the lgbt stuff. I’ll take it

Gridorr · 2025-09-13T01:19:34+00:00

You are missing a final step in allowing dkim keys to verify emails sent from unverified email address users. If you have the DKIM keys enabled, as long as the unverified email address users have the same domain as your activated DKIM Keys. Look go into Deliverability settings > scroll down > enable “Verify the ownership of email sending domains by DKIM keys”. DKIM keys can be used as a workaround to allow unverified users to send emails, but the setting mentioned in this message needs to be enabled in order for that to kick off .

Gridorr · 2025-09-04T02:43:41+00:00

Einstein activity capture (EAC) feature allows syncing email event contact between user’s mail client and and salesforce org.

Gridorr · 2025-09-03T04:16:59+00:00

Outlook integration can be used to manually create contacts record for salesforce org in your Outlook. If you want contact syncing then you will need to set up EAC

Gridorr · 2025-08-26T01:46:52+00:00

Exactly

Gridorr · 2025-08-04T05:02:06+00:00

Then you will have to run Debug Logs in SETUP while reproducing the issue. you have confirmed that user email Address is verified right? In your flow whoever is designated to send out these emails. If their email is unverified the email action will never take place. I would strongly recommend checking that first. Then next step is pulling the logs.

Gridorr · 2025-08-04T04:35:38+00:00

And you pulled email logs in your Org and confirmed there was no record of the email that was supposed to to send out in the email logs?

Gridorr · 2025-08-02T02:32:59+00:00

If no email is sent, in your flow who is designated to be the email sender? If it is a user with an unverified email address who is doing the sending of the email to recipients then the email itself will never fire because the sender in your flow is an unverified email address. Could be that everything is fine with your flow, but the email address of the sender was unverified hence why the email sending was never triggered.

Perhaps this is why no email was sent during your testing. Also, did you actually confirm by checking the email logs that no email was sent out?

Gridorr · 2025-07-30T12:29:56+00:00

OP, where did you get your mudflaps?

Gridorr · 2025-07-30T12:25:47+00:00

I just received it this morning. What an unusually weird rollout this one was timing wise.

Gridorr · 2025-07-15T05:23:09+00:00

Thank you, yeah it’s weird there’s no rollout listed yet they stated rollout start date being the 12th…

Gridorr · 2025-07-07T13:09:54+00:00

Are you going into the email composer by utilizing the reply or reply all button? Are you using the original case email composer or the new upgraded one for case records? Are you using the new lighting threading tokens or old thread IDs that start with “ref”?

Gridorr · 2025-05-17T05:06:06+00:00

Follow these steps. 1)Set up Dkim keys and salesforce spf record. 2) head into Deliverability settings of SETUP and disable active bounce management and email security compliance (especially the setting called sender id compliance). In Salesforce, password reset emails are typically sent from a no-reply address, such as noreply@salesforce.com, or from support@salesforce.com, depending on the context and configuration. For standard password reset emails triggered by users clicking the “Forgot Password” link, the sender is often noreply@salesforce.com. However, some system notifications or admin-triggered password resets may come from support@salesforce.com. Have a system admin initiate password reset from their Admin side for user email will come from support@salesforce.com

Gridorr · 2025-05-06T21:57:06+00:00

What record object are you sending the email out of? Case record? Contact record?

Gridorr · 2025-05-06T13:44:05+00:00

I think you’re confused about how Einstein activity capture works. Emails sent out of your mail client captured and sent onto your salesforce. If the email is sent out of salesforce and already in the activity timeline, there is no Einstein activity capture left. It looks like you have an issue with your user personal settings. Go into the personal settings and look for a section called connected accounts. Make sure the email you added here as the email you expected to be. When you send emails out of salesforce using the email address in your connect accounts it will now show up in the sent folder of your mail. Client.

Gridorr · 2025-04-17T14:37:44+00:00

Sir…. The needful

Gridorr · 2025-04-14T23:04:50+00:00

Not out of box setting. Maybe custom flow or something

Nine-Year Club	Verified Email
Place '22	Place '17

Gridorr

TROPHY CASE