Building Production-Ready Flows in Salesforce

This is a visual representation of why your team hates Salesforce 😡... Throughout my Salesforce journey, I've seen it all (Insert "Emotional Damage" meme 🫠). One common issue I see often are Flows that "work," but that are not optimized for scale or user experience. They cause ugly error messages, delays on future iteration, & inaccurate data that plague users on a daily basis. Check out the Flow examples below: Version 1 works. It's simple, has only 2 elements, so what's the big deal? To find out, let's look at the #'d boxes in Version 2: 1️⃣ Element Descriptions: Please...for the love of Benioff... document the "Why." Each element allows you to write a description, which explains what it's doing technically and why it's important to the process you're building. This context is essential for future changes and for those that come after you. If another admin can't read your descriptions and understand what it's doing, you haven't documented enough! 2️⃣ Decision Elements after Get Records Elements: In Version 1, the "Get Account Id" element finds a related Account record associated with the triggering Opportunity. What happens if the criteria for the search doesn't find a record? ❌ Flow Error ❌. By checking to see if the Get Records element finds what it's looking for, you can prevent a poor user experience and ensure other automation runs on schedule. 3️⃣ Fault Paths & Error Handling: A fault path is an error handling path that triggers when the element wasn't able to process a change (Update, Create, Delete) in the database. By default, users are presented with red text and a cryptic message without enough readable context to troubleshoot themselves. In Version 2, we've add a fault path for every Create Records element to notify the Salesforce team of new errors. No one likes it when automation fails, but it's a magical experience to reach out to a user and let them know you're already working on it! 🪄🎩🐇 4️⃣ Tracking Performance/Usability: This one is a game changer... What good is an active Flow if you can't measure its performance or usability? Create a custom object called "Automation Saved Time." Any time you add to a Flow, estimate the amount of time the automation saves and add it to a variable. At the end of the Flow, create a new Automation Saved Time record adding the aggregated time for all elements. It'll help answer some amazing questions: a) How much time has your Flow saved users? b) How often has Flow is been run? c) Is this Flow useful? All questions you can only assume the answers to without this data! Build a dashboard and show it to internal stakeholders, so they understand the value you're adding. 5️⃣ Reuse & Recycle: Rather than building a new Flow element each time you need it, connect to an existing element. In this example, we are connecting both fault paths to the same email alert. "In a world full of Version 1s, be a Version 2 💪🏻" #salesforce #salesforceflow #automation #bestpractices #benioff

A few months ago, I deployed a Flow that looked perfect in sandbox. It automated case assignments, sent notifications, and even updated SLA records in real time. In testing, it worked flawlessly. But when we deployed it to production, something broke — and fast. Users started reporting errors like: “Too many SOQL queries: 101.” The culprit? A Record-Triggered Flow that fetched related records inside a loop. It was doing exactly what I told it to do — not what it should’ve done. That night, I refactored the Flow with these changes: 1️⃣ Pre-Query Data (Bulkify): Moved all “Get Records” actions outside loops and stored results in collection variables. 2️⃣ Use Fast Elements: Replaced “Update Records” inside the loop with Fast Update to process data in bulk. 3️⃣ Add Entry Criteria: Restricted the Flow to run only when key fields changed — reducing unnecessary triggers. 4️⃣ Combine Logic: Merged two Flows on the same object into a single Decision-based Flow to simplify debugging. 5️⃣ Debug with Bulk Data: Simulated large datasets in a full sandbox to test for scale, not just function. After the fix, the same Flow handled 5,000+ case updates in a single batch — without hitting a single limit. That project taught me something I’ll never forget: “A Flow that works for one record isn’t success. A Flow that scales for a thousand — that’s architecture.” Since then, I’ve made it a rule — every Flow I build must pass the “Bulk Test.” Because Salesforce doesn’t fail when it’s complex — it fails when it’s untested for scale. #Salesforce #FlowBuilder #TrailblazerCommunity #Apex #Automation #GovernorLimits #Optimization #SalesforceDeveloper

Flow first isn’t always the best advice. Sometimes clicks create more risk than code. A lot of teams treat Salesforce automation like a religion: admins pick Flow, devs pick Apex, and everyone defends their side. That’s the mistake. The real skill is choosing the simplest tool that won’t collapse under scale, complexity, or edge cases. Here’s what no one tells you: 1. Start with Flow for simple + admin-owned work → Field updates, notifications, basic record creation, and guided screen experiences ship faster with clicks. 2. Use before-save flows for efficient record updates → They reduce extra DML and stay clean when the logic is straightforward. 3. Reach for Apex Triggers when logic gets non-linear → If you need maps/sets, dynamic branching, or complex cross-object rules, code stays readable and controllable. 4. Plan for volume, not just today’s data → Triggers handle large batches more reliably; flows can hit CPU/element limits under load. 5. Don’t ignore “undelete” and advanced transaction needs → Flows can’t run on undelete, and triggers give better options for error handling and traceability. 6. Debugging matters more than building → Flow fault paths are helpful, but Apex enables richer logging, try/catch patterns, and clearer root-cause analysis. Read Exception Path in Flows - https://lnkd.in/ghkv4ymk 7. Avoid stacking multiple automations without a plan → Mixing many flows and triggers on one object can create unpredictable order-of-execution surprises. 8. Use a hybrid when you need both speed and power → Let Flow orchestrate, then call invocable Apex for the heavy lifting. 9. Trigger / Apex Codes require min 75% code coverage → Apex codes require you to write test class with minimun 75% coverage Good automation isn’t about being “no-code” or “all-code.” It’s about building something your org can maintain, scale, and trust—six months from now, not just in today’s sprint. Read more about flows here: https://lnkd.in/gPQP29CN ♻️ Reshare if you find this useful 👉 Follow me for more practical Salesforce build decisions. #Salesforce #SalesforceAdmin #SalesforceDeveloper #Apex #SalesforceFlow #CRM #Automation #DevOps #EnterpriseSoftware #Architecting

When an Account owner changes in Salesforce, business users often expect all related records (Contacts, Cases, Opportunities, Orders, Invoices, etc.) to follow the new owner. But this is not standard behaviour for custom objects, and even some standard ones too. There are common ways to approach this — multiple Flows, object-specific triggers, or scheduled jobs. Each works, but they tend to be either hard to maintain, fragmented, or not real-time. I wanted a design that was scalable, maintainable, and declarative where possible. Here’s what I built: 1 - A record-triggered Flow, which detects the Account ownership change. 2 - The Flow invokes a single Apex method that performs the ownership cascade. 3 - A Custom Metadata Type defines which objects are included, and which lookup field ties them to the Account. - The Apex dynamically queries and updates the related records in a bulk-safe way. This approach isn’t the only valid one. You could use separate triggers on each child object, or even solve access concerns with Territory Management or sharing rules. But in this case, explicit ownership needed to change, and I wanted to avoid scattering logic across multiple places. What makes this design valuable is how it balances trade-offs: • Configurable: adding or removing objects is a metadata update, not a code change. • Bulk-safe: it can handle a single update or a large batch without hitting limits. • Separation of concerns: Flow handles orchestration, Apex handles logic. • Hybrid approach: declarative where possible, programmatic where necessary. Lesson learned: the best Salesforce solutions often come from combining declarative tools with programmatic techniques, rather than forcing one approach. By using metadata to control Apex behaviour and letting Flow handle orchestration, you get something that is scalable, flexible, and still admin-friendly. #Salesforce #SalesforceArchitect #SalesforceFlow #Apex #CustomMetadata #SolutionArchitecture #Automation #ClicksNotCode #LowCode #ProCode #SalesforceConsultant #SystemDesign

Flow Like a Developer Always catch your errors and handle them appropriately. Unhandled Exception emails should be the exception, not the rule. We should design our automations to handle not only the happy path but also where a path may turn not so happy. When starting, we build towards our intended design. How we envision every record to be created, what the user does exactly. --- But, we all know that bugs happen, folks don't follow the process, or data happens to be...bad 🤫 So, we should handle things well, so the user doesn't get a horrible error message, and freak out, and maybe text you, call you, DM you, email you. That would never happen, right? --- As a rule of thumb we should always have error handling for: 👍 DML operations (Create, Update, Delete) - do we want to roll back? do we want to continue? 👍 Get elements - technically not needed, but I always like consistency 👍 Get element null checks - if the get resource returns nothing, will your Flow break? 👍 Actions/Callouts - if interacting with Invocable Apex or an HTTP callout, how will you handle if the action fails? Sometimes errors shouldn't stop a process, but instead take a different path. If you don't handle your errors, your entire Flow fails, versus only one part. --- Bonus tip? Be consistent in your error handling, and invest in reporting. I love Nebula Logger as an Open Source project and it has all the elements I need. Additionally, I have a Slack channel for all unhandled exceptions. That way the team can see each one, and comment on them to determine next actions or if a ticket needs to be created. #salesforce #salesforceflow #flow #salesforceadmin #flowlikeadeveloper

Most orgs I walk into have a Flow explosion problem. Multiple Flows with similar logic… each a maintenance nightmare. Instead of creating multiple record-triggered flows, you can use Custom Metadata & a single Flow. → Store your criteria & actions in metadata (object, field, operator, value, action type). → In the Flow, fetch those rules at runtime. → Loop through them → execute dynamically. It’s like parameterizing Apex… without code. The Why ↓ → Scalability: Add new rules by creating a metadata record, no more Flow duplication. → Maintainability: Change logic in a spreadsheet-like interface, not inside complex Flow logic. → Deploys Easily: Custom Metadata migrates with change sets and DevOps tools, making complex logic deployments a breeze. → Business-Friendly: Junior admins can manage rules without touching the core Flow. → Pro tip: For more advanced scenarios (dynamic field updates, cross-object actions), add a small Invocable Apex executor. Keep Flow simple, keep logic admin-configurable. 👉 If you are a Salesforce developer and preparing for interviews, grab free LWC Interview Preview Guide → https://lnkd.in/eADiGBGU