* Sales Cloud - Best Practices *

Hi @Manthan Ghorpade - @Abaid Ur Rehman is correct that you can't override validation rule execution order during Lead conversion. But there's a cleaner architectural solution he didn't mention: 

The Best Practice: Consolidate into One Validation Rule

Instead of separate rules for Country and State, merge them into a single validation rule that catches all missing address fields and returns one error message:

AND(    ISPICKVAL(RecordType.Name, "Your Record Type"),    OR(        ISBLANK(BillingCountry),        ISBLANK(BillingState)    ))

Error message:

"Billing Country and State are required for Territory assignment. Please complete both fields before saving."

One rule = one error = clean UX during Lead conversion. 

Prevent at Lead Level (Cleanest Long-Term Fix)

Add validation on the Lead object itself before conversion is even attempted:

AND(    ISBLANK(Country),    ISBLANK(State))

Error: "Country and State are required before converting this Lead."

This stops the user at the Lead record — before conversion triggers Account validation entirely. 

For Territory Model specifically:

 This is actually the recommended Salesforce pattern — enforce address completeness at the Lead stage so Territory assignment on the resulting Account never fails downstream. 

Your Flow-based approach was architecturally sound but Lead conversion's execution order makes it unwinnable — the validation rule always fires first on the target object. 

If this helps, please mark as Best Answer!

Hi @U k -  good setup description, makes the problem clear.  

The core challenge here is mapping the Meta Campaign ID to the correct Sales Cloud Campaign ID

 before or during the lead push-back process. Here are your options cleanest to most complex:  

Option 1 — Custom Field Mapping (Simplest, Recommended First) 

Add a custom field Meta_Campaign_ID__c on the Salesforce Campaign object. When creating campaigns in Sales Cloud that correspond to Meta campaigns, store the Meta Campaign ID in this field manually or via import. 

Then in Marketing Cloud, when the Meta lead arrives with the Meta Campaign ID in the payload: 

• Use a Journey Builder Decision Split or Automation Studio Query Activity to look up the Sales Cloud Campaign where Meta_Campaign_ID__c matches the incoming payload value
• Pass the matched CampaignId when pushing the lead back to Sales Cloud as a CampaignMember

Option 2 — Marketing Cloud Connect + AMPscript Lookup

In your lead capture email or landing page process, use AMPscript to query the Sales Cloud Campaign object: 

VAR @metaCampaignId, @sfCampaignIdSET @metaCampaignId = AttributeValue("Meta_Campaign_ID")SET @sfCampaignId = Lookup(  "Sales_Cloud_Campaigns_DE",  "CampaignId",  "Meta_Campaign_ID__c", @metaCampaignId)

Where Sales_Cloud_Campaigns_DE is a synchronized Data Extension from Sales Cloud Campaign object via Marketing Cloud Connect. 

Option 3 — Automation Studio Query to Auto-Assign

If leads land in a Marketing Cloud Data Extension first, run a nightly or real-time SQL query to join on Meta Campaign ID and stamp the correct Sales Cloud Campaign ID before the lead is pushed back:

SELECT     l.SubscriberKey,    l.Email,    l.Meta_Campaign_ID,    c.CampaignIdFROM Lead_Capture_DE lJOIN SF_Campaign_Sync_DE c     ON l.Meta_Campaign_ID = c.Meta_Campaign_ID__c

Then use this output DE as the source for your Sales Cloud lead push. 

My Recommendation for your architecture:

Option 1 + Option 3 combined is the most maintainable. The custom field on Campaign is the single source of truth. The query auto-resolves the mapping without manual intervention per lead. 

One thing to validate — confirm your Salesforce Labs Meta connector payload field names so the Meta Campaign ID is consistently available in the DE before building the join logic. 

If this helps, please mark as Best Answer!

Hi @Naveenakumar Panchyal - great diagnosis on the root cause. @Kundan Kumar Jha's answer covers the fix well. One addition directly addressing your constraint:  

If you want to avoid deleting OR remapping line items, there's a quicker sandbox-specific workaround:  

Option 4 — Enable the Standard Pricebook in Sandbox + Re-sync via Apex 

// Run in Anonymous Apex to identify broken OLIsList<OpportunityLineItem> brokenOLIs = [    SELECT Id, PricebookEntryId, Product2Id     FROM OpportunityLineItem     WHERE PricebookEntry.IsActive = false     OR PricebookEntryId = null];System.debug('Broken OLI count: ' + brokenOLIs.size());

This tells you exactly how many records are affected before you touch anything. 

Then match to active sandbox PricebookEntries by Product2Id and bulk update via Data Loader — no deletions needed. 

Root cause reminder for future refreshes:

 When refreshing a Partial Copy sandbox, always include PricebookEntry and Product2 in your sandbox template object selection. This prevents orphaned line items entirely. 

If this helps, please mark as Best Answer!

Hi @Charlie Kaye — you've identified the exact gap in both suggestions above.  

You're right. If the Event record isn't updated, nothing triggers the Flow or Apex. This is the core problem with future events silently becoming "past" — there's no DML event to hook into.

The clean solution is a two-part approach:  

Part 1 — Record-Triggered Flow (handles real-time changes)

 Fires on Task/Event create/update/delete. Decision element checks ActivityDate <= TODAY() AND OwnerId = Opportunity.OwnerId. Updates custom Last_Owner_Activity__c field on Opportunity. This covers 90% of your scenarios.  

Part 2 — Scheduled Flow (handles the midnight gap)

 Runs daily. Queries Activities where ActivityDate = YESTERDAY and OwnerId = Opportunity.OwnerId. Updates the custom field only if this date is more recent than the current stored value. 

This is the only fully native solution to the "future event crosses midnight" problem without custom fields on Event. 

If you can use Apex, a single @Schedulable class running nightly is cleaner and more governor-limit-safe than a Scheduled Flow querying large activity datasets. 

 Happy to share the exact Flow configuration or Apex pattern if useful. 

If this helps, please mark as Best Answer!

Hello,  

I think you are running into some of these challenges because Salesforce's standard lead model wasn't really designed around a pure account-based sales motion. 

If your reps are prospecting within known target accounts, I'd be hesitant to make the Account relationship mandatory on the Lead object. That's where a lot of reporting and visibility issues start to appear in day-to-day operations. 

From my experience, there are two options. Either keep leads completely separate until they are qualified and ready for conversion or go all-in on an Account → Contact model if your sales team is already working from assigned accounts. 

If you want to keep the Lead process, a tool like LeadAngel or LeanData can help bridge the gap. It automatically matches Leads to existing Accounts and routes them to the right account owner, so reps don't have to manually figure out who owns what. It won't change Salesforce's native behavior around Lead activities, but it does make account-based prospecting much easier to manage. 

Personally, I'd first revisit whether those records should be Leads at all. Your team already knows which accounts they're targeting, and that's usually a sign that Contacts tied directly to Accounts may be a better fit. The reporting becomes cleaner, LinkedIn workflows are simpler, and account-level visibility is much easier to maintain. 

Just my two cents—I've seen a lot of teams try to force account-based selling into a lead-centric process and end up fighting Salesforce more than they need to.

No, you can’t directly add List Emails as a single activity on a Project in Salesforce. List Emails are tracked at the recipient level, not as one grouped activity. 

Best options: 

•  Use Campaign as the main container (best native approach) 
•  Build a report on Campaign + Email Activities and group it to see sends in a summarized way 
•  If you really need “one email = one activity”, you’ll need a custom object with Flow to log each send 

That’s basically the limitation and your practical options.