#Einstein Analytics1 discussing

 Hi, I’m working on a scenario where a client previously had Einstein Activity Capture enabled, which synced calendar events into Salesforce. Even after disabling the sync, some recurring events are still being created. 

I need to clean up these EAC-generated events, but want to make sure I don’t delete any manually created or standard Salesforce events. 

What’s the best way to identify and differentiate EAC-generated Events from normal Events in Salesforce? Are there specific fields or indicators that can be used? 

@Debanand Pati

This is one of the more frustrating gaps in EAC's data model, and the subject prefix approach you've been trying ("Email RE:" vs "Email:") is brittle for exactly the reason you identified. Once a thread starts, everything gets "RE:" regardless of direction. Here's how to actually solve it.

The right field to use is "Incoming" on the EmailMessage object.

When you enable "Sync Email as Salesforce Activity" (Summer '25 for new orgs, or for existing orgs that've had EAC reset by Support), EAC writes emails as proper EmailMessage records in the Salesforce database.  

That object has an Incoming boolean field = true for inbound, = false for outbound, which is exactly the classification you need. No subject parsing required. 

Flip Incoming = false for outbound. You can also join back to the Task via ActivityId if you need to cross-reference with other activity data.

Now, the catch you need to be aware of. If your org enabled EAC before Summer '25 and hasn't been reset, emails are still living in AWS, not as real EmailMessage records. In that state, the EmailMessage query above returns nothing for EAC-captured emails because they simply don't exist as platform records yet. That's why the Task approach felt like a dead end. Tasks were all you had, and Tasks don't carry FromAddress or the Incoming flag.

If you're in that older EAC setup, your options are:

Contact Salesforce Support to reset and re-enable EAC under the Summer '25 architecture. This gives you the new EmailMessage-based sync going forward. Historical data won't migrate automatically (Salesforce is still working on that tooling), but new emails will be properly classifiable.

In the meantime, for existing Task-based data, the subject prefix approach is the only native handle you have, but you can make it slightly less fragile. Match on whether the Task's assigned user OwnerId matches the sender. If the rep is the owner and the email subject starts with "Email:", it's outbound. If the subject starts with "Email RE:" and the rep is the owner, it's likely an inbound reply. Not perfect, but it gets you to around 85% accuracy on clean threads.

The real fix is getting onto the Summer '25 data model. Once you're there, Incoming on EmailMessage is clean, reliable, and reportable natively without any subject parsing workarounds. 

I hope this answers your doubts. thanks! 

It looks like this link has the information I need related to this -

Considerations for Excluding Data from Einstein Activity Capture

• Events that don’t have attendees sync even if the organizer's domain is on the Excluded Addresses list.

- But why is this a default setting?  So, it appears that users are going to have to make all events without attendees as private to keep them out of Salesforce.

• When you exclude an email address or customer domain, here’s what happens regarding synced events.
  • New events don’t sync between Salesforce and the connected accounts.
  • New events aren’t stored in Salesforce.
  • Previously synced events no longer sync, but they remain in Salesforce or the connected accounts.

- So, for events that shouldn't be in Salesforce after excluded domains are added, before deleting these in Salesforce, I would make sure to disable Remove deleted events in the configurations advance setting, and then go back and delete the unwanted events.

• When you exclude an email address or customer domain, several rules determine whether the related emails and events are captured and synced.
  • The admin’s list applies to the entire org, and has priority over users’ lists.
  • When email or event recipients include multiple Einstein Activity Capture users and a customer, Einstein Activity Capture users must add the customer’s email to the Excluded Addresses list.
  • When email or event recipients include Einstein Activity Capture users and multiple customers, Einstein Activity Capture users must add at least one customer email or domain to the Excluded Addresses.

- The last bullet isn't clear to me about multiple customer emails on an email or event.  If you have one of the customers emails on the excluded list, does this mean the entire email or event is excluded even if the other customer email isn't on the exclude record, but exists as a contact in Salesforce? 

If you get an answer, let me know, having the same issue... super unclear what to put here and the error I receive is: "ConnectApi.ConnectApiException: Application Name is a required field providing existing registered ai applicaton" 

I have already debugged to confirm the name I chose is set. I tried using the developer name of my prompt and a few common ones like SalesGPT, PlatformGPT, etc... to no avail. This is such a weird requirement that actually blocks calling prompts from Apex and there is almost no useful documentation surrounding it.