Using AEP for Lead Collection Before Salesforce - Experiences?

[JeanBaro_]

Hello AEP Community,

We're looking to use AEP as the initial step (Lead Quality GATE) when collecting new leads before they are sent to Salesforce. The main benefits we expect from this design are:

• Utilizing AEP's native capabilities, including Identity Resolution, Partner Cookies (FB, Google, etc), Web SDK, Deduplication, Data Quality, Removal of fake leads (bots), and Stitching.
• Maintaining a mostly unidirectional flow of lead data. From AEP to Salesforce in NEAR REAL TIME.

Has anyone implemented a similar setup? I'd love to hear about your experiences and any tips you might have.

P.S.: I've added a simple high-level diagram to explain the idea we're trying to implement.

Thanks!

[sreeCharan73]

hello @JeanBaro_ 

Just to understand and give a context,
a. How are you planning to achieve a near RealTime sync from AEP to SFCRM? guessing the SFCRM OOTB destination for updating Leads & Contacts.

Here: https://experienceleague.adobe.com/en/docs/experience-platform/destinations/catalog/crm/salesforce#p...

The mandatory field is the "Id" - salesforce Entity Id field, which you would need to create as part of the AEP and pass it on. And this field is more important as SFCRM stitches all the related on this meta Identifier.
my question, How do we ensure that the id generated does not overlap with other ids, present in SF.
There might be a race-condition in assigning Ids. Either we have a definite pattern for AEP created leads, which would never overlap with SF Ids. Also then the SF indexing should not be impacted.
b. There might be the API License limitations on SF. https://experienceleague.adobe.com/en/docs/experience-platform/destinations/catalog/crm/salesforce#e...
It is better to have a review this with the SF architect. 

[JeanBaro_]

I am not sure I understand your reply.

But Salesforce will have its own ID for the Leads (auto generated) and the ID from Adobe will be stored in the Lead object in Salesforce as an ExternalID (like a correlation ID).

We are not going to use the SF CRM Connection, and will build a integration using AEP APIs, as we also need to synch custom objects (which are not supported by the SF CRM connection)

Please, let me know if my answer addresses your concerns. 

Thanks for taking time to reply! 

[sreeCharan73]

hello

My idea was, either we use OOTB destination or build a custom destination using Destination SDK for SFCRM. 

Going with the Composite Upsert API on SFCRM, would work if the leads are only generated using AEP on SFCRM. But in the diagram I see that SFCRM UI, where agents would create leads and we are expecting a sync to AEP(near realtime) and the dedup to happen and then synced back to SF.
Since the destination would be trying to upsert(update or insert) using the Ext_IDs and not referencing SFIDs. So it would end up having duplicates in SFCRM for those, that are not already synced nor generated.

Also, I support the same idea, as mentioned in your other post 
Re: Using AEP as the Main Hub for Leads: Feasibili... - Adobe Experience League Community - 686471, that we should ideally limit using CDPs for lead Management. In other way, to achieve Quality gate on leads, we could first receive all leads onto CRM system and use AEP to update(stitch) using the extID. Because lead acquisition is an expensive and important step, than MDM.

Thank you for very good question/idea. This is one of the most commonly thought about(or should be), but less asked ones in CRM-CDP integration.

[JeanBaro_]

Thanks for your insights @sreeCharan73 

First, I want to clarify that unfortunately I'm not an expert in Salesforce or Adobe, but as an Enterprise Architect, I’m helping our teams create a solid, robust, and easy-to-understand solution for managing leads across various lines of business.

To address your points:

1. Salesforce UI and Lead Updates: The Salesforce UI will not update the Lead object directly. Instead, it will use AEP as an intermediary. This ensures that all lead record updates (create or update) go through AEP first, regardless of where it comes from.

   

2. ID Management: In Salesforce, each Lead will have that standard SF internal unique ID PLUS an External ID field that will hold the AEP unique ID.

3. Sales Process: The sales team will use Salesforce to manually convert leads (e.g., through calls). Once a lead is converted (product sold in the transactional system), both AEP and Salesforce will be updated via an event-based design, so that they will know the status of that PRODUCT INTEREST that the Lead is linked to.

Regarding my questions:

• Deduplication Speed: Can AEP deduplicate leads in near real-time (within seconds)? This is crucial since the quality check and deduplication need to consider leads in the AEP database, customer information from our MDM (that will be injected into AEP), and possibly old leads stored in Salesforce.
• Data Retention: We plan to store leads in AEP for no longer than 2 years, but they will remain in Salesforce for more than 2 years, potentially over 5 years.
• Product Interests: Leads can have multiple product interests linked to them. While one product might be converted, others might still require work from the sales and marketing teams. (See the simplified diagram). 

Thanks again for your feedback and support!