#Flow158 debatiendo

Hi @ROHIT PIPPERA

As a fresher, you don't need to be an expert in debugging, but you should know how to identify and troubleshoot common Salesforce errors. 

Focus on these key areas:

1. Debug Logs: Learn how to check logs and identify errors.
2. Flow Debug: Practice debugging Screen Flows and Record-Triggered Flows.
3. Apex Debugging: Understand System.debug(), exceptions, and common DML errors.
4. Permission Issues: Learn how to troubleshoot Profiles, Permission Sets, OWD, and Field-Level Security.
5. Validation Rules: Understand why records fail to save and how to identify the issue.
6. SOQL Errors: Practice identifying query errors and governor limit exceptions.

My suggestion: Create a few errors intentionally in your practice org and try to fix them yourself.

In interviews, don't just explain what Debug Logs are. Be ready to explain how you identified and resolved an issue. 

Practical troubleshooting skills will definitely help you stand out as a fresher. 

All the best!

Hi @ROHIT PIPPERA

Screen Flows are widely used in real-time projects to collect user inputs and automate business processes. 

I suggest practicing these scenarios:

1. Case Creation: Collect customer issues and assign cases to support queues.
2. Lead Assignment: Capture lead details and assign leads based on region.
3. Employee Onboarding: Collect employee information using multiple screens.
4. Opportunity Creation: Create opportunities using a guided Screen Flow.
5. Leave Request: Allow employees to submit leave requests.

For Screen Flow Distribution, focus on:

• Adding flows to Lightning Record Pages and App Pages.
• Launching flows using Quick Actions.
• Passing Record IDs using input variables.
• Using flows in Experience Cloud.

My suggestion:

 Start with Case Creation and Lead Assignment. Practice Decision elements, input validation, and fault handling. 

Don't just follow Trailhead steps. Build these scenarios independently in your practice org.

All the best!

Hi Justin, 

I would avoid creating 68 separate email paths. A better approach would be to make the solution data-driven by creating a custom object such as Lead Email Schedule, with fields like Lead Source, Days After Creation, Email Template, and Active.  

The Flow can identify the Lead Source and use the schedule records to determine which email should be sent and when. This keeps the Flow much easier to maintain and allows you to add or change Lead Sources and email timings without redesigning the entire Flow. With 17 scheduled paths for each Lead Source, the Flow could become difficult to maintain. 

Hi @Pradeepthi Nagarthi

Good question! In real-time projects, we don't decide between Flow and Apex based on personal preference. It mainly depends on the requirement and its complexity. 

Here are a few things I normally consider:

1. Simple Automation: If the requirement involves updating records, sending emails, or creating related records, I prefer Flow.
2. Complex Business Logic: If there are complex calculations, multiple conditions, or advanced processing, I prefer Apex.
3. Large Data Volumes: For processing thousands or millions of records, Batch Apex or other asynchronous Apex options may be more suitable.
4. External Integrations: For complex API integrations, custom authentication, or advanced error handling, Apex is usually a better choice.
5. Maintenance: If admins need to make changes frequently, Flow is generally easier to maintain.
6. Performance: I also consider governor limits, bulk processing, execution time, and future scalability.

Simple Example:

If an Opportunity is Closed Won and we need to create a follow-up Task, I would use Flow.

But if we need to process thousands of records with complex calculations and external API calls, I would consider Apex. 

My suggestion:

Start by checking whether Flow can handle the requirement efficiently. If the logic becomes too complex or needs capabilities better suited to code, go with Apex. 

Also, remember that we can combine both using Flow and Invocable Apex when needed.

The goal is not to use more code, but to build a solution that is simple, scalable, and easy to maintain.

Hope this helps! 

Thank you, 

Venkat Yadav.

Hi Vikas,

Test Connection and the flow run are not the same session. Test Connection uses you. A Prep flow on Tableau Server runs with the credentials embedded on the flow, under the server account that executes flows. Other extracts can keep working while this flow doesn't, if this one is the only place those credentials aren't embedded.

The message you pasted is on the output step: unable to connect to that data source. That's the output connection, not automatically the Oracle input. A flow that writes several files has an output connection of its own, and that's the one I'd open first.

On the Oracle side, the process that actually runs the flow has to see the JDBC driver and oracle.properties. Dropping the file under flowprocessor while that process is already up doesn't always get picked up. Restart the flow services after the file is in place, then run this one flow again.

I wouldn't call this a tnsnames problem until the output step still can't connect when you run it as the same account the server uses. I also don't have a published defect for 2026.2.1 that matches this, so I won't invent one.

@Guilherme Sequine Saquei! 

O evento chegar no flow e no Data Cloud confirma que o carrinho abandonado está entrando. A vitrine é outro passo: ela só repete os produtos quando o Repeater tem uma fonte, e cada campo de dentro (imagem, nome, preço e link) é merge field dessa mesma fonte. Com o layout estático, o teste envia o e-mail e a vitrine vem vazia ou fixa. 

O data graph só alimenta a vitrine quando ela está em Data Graph Attribute. Nesse caso ele precisa incluir o DMO dos itens do carrinho, no caminho Unified Individual → Unified Link Individual → Individual → itens, com nome, preço, imagem e URL marcados. O e-mail usa o graph padrão do Setup (Customer Engagement), salvo se tiverem colocado outro na própria mensagem. Esse graph atualiza na agenda, então o carrinho pode já estar no Data Cloud e ainda não estar disponível para a vitrine. Um graph só de perfil envia o e-mail e não tem linha de produto para repetir. 

Para esse teste, liguem a vitrine no evento, que é o payload que vocês já validaram. No e-mail, aba Data Sources, adicionem o evento de carrinho abandonado (o mesmo do flow). No Repeater, definam o Repeater Source nesse evento, nos itens do carrinho. Dentro da vitrine, a imagem entra como Merge field, e nome, preço e URL do botão também, todos dessa mesma fonte. Salvam e fazem o preview com a pessoa que gerou o evento. Se nome e preço aparecerem e a imagem continuar em branco, incluam o domínio da imagem em Setup → Trusted URLs.

Hey Misty, 

Your read is accurate: per Salesforce's own docs, Related Record Matching is an org-wide, all-or-nothing setting, when it's on, ECI runs its own algorithm (participant email/domain matching against Contact, Lead, Account) and populates the Related Record field automatically. If you want to run your own Flow-based matching logic instead (your name-against-Contact/Lead + subject line idea), you have to turn Related Record Matching OFF entirely, then a Flow becomes the only thing setting that field. You can't layer a supplemental Flow on top of the native matching to "catch the extra 10-20%", it's one or the other, not additive. 

Given that, your options really are: 

1. Turn off native matching, build your own Flow to replicate ECI's built-in logic PLUS your extra fallback rules (name-against-Contact/Lead, subject line parsing). This means you inherit responsibility for the baseline matching ECI already does well, not just the edge cases, that's a bigger lift than it initially sounds. 

2. Keep native matching on, and instead build a separate Flow/batch job that runs afterward on unmatched records only, checking if Related Record is null, then applying your own supplemental logic to update it. This avoids fighting the native system since you're only touching records ECI already gave up on, not replacing its matching entirely. 

3. Turn on Einstein Activity Capture integration alongside ECI, per Salesforce's own guidance, this specifically enhances guest participant matching quality, which sounds directly relevant to your "joining from a car/conference room" problem, worth testing before building custom logic at all. 

On

or similar tools: since ECI's matching is a Salesforce-side process, not tied to which video/transcription vendor recorded the call, a third-party transcription add-on wouldn't conflict with ECI's matching logic, but it also wouldn't replace or feed into it automatically. It solves a different problem (better transcript quality) than record-matching itself. 

Given the scale you're describing, option 2 (supplement only nulls, don't disable native matching) is usually the least disruptive path, worth prototyping that before considering a full matching rebuild. 

Reference:

@Lena Wong

You're right the business rule doesn't care who owns the Quote. The risk comes from how the platform stores the share, not from the rule. 

Where the Quote owner matters (platform mechanics, not business logic) 

A Flow created QuoteShare is a manual share (row cause "Manual"). Salesforce deletes manual shares on a record when that record's OwnerId changes. Your Flow most likely triggers on events like Quote created or Account owner changed. A Quote owner change isn't one of those events, so: 

1. The ERP (or a user or mass transfer) changes the Quote's owner.
2. The platform silently deletes the share the Flow created.
3. Nothing re-runs the Flow, so the Account Owner loses access even though the business rule says they should have it.

Fixes, in order of preference: 

• Add a trigger path on Quote update when OwnerId changes, so the Flow recreates the share.
• Add a scheduled reconciliation that compares expected and actual shares. This also catches other drift.

A related edge case:

if the Account Owner is also the Quote owner, they already have access. The Flow should skip creating the share in that case, because inserting a share for the owner is rejected or ignored. 

(it creates Quotes under a fixed integration user and never updates them), this risk mostly goes away, and the Account owner, region, and bulk-load gotchas are what remain. I can't confirm that from here, so it's worth asking the ERP team. 

If every sales user is in the same Permission Set Group, that group can't tell Field Sales from back-office, so it doesn't help as the identifier. Option 2 only works with a separate, standalone permission set (for example