Sebastian Kochanowski

🧠 Why Aren’t More Salesforce Developers Using Design Patterns? Whenever I chat with Salesforce devs who’ve got 3+ years of experience, I notice a common gap: 👉 Solid Apex skills, but weak understanding of design patterns. Not because they’re not smart. But these patterns often feel abstract, over-engineered, or hard to apply in real Salesforce projects. So I decided to do something about it. 📘 I’ve put together a set of straightforward, no-fluff notes on common Salesforce design patterns—tailored specifically for real-world projects. Think of them as: ✅ A reference guide during crunch time ✅ A bridge between writing code and thinking like an architect ✅ A tool to level up your dev game without the overwhelm Read more https://lnkd.in/grkmxfdC

180

15 komentarzy

If you’re preparing for an interview in the Salesforce ecosystem, this is one to remember 👇 During my conversation with Weronika Tołłoczko-Żagan from Craftware, our Diamond Sponsor of the Salesforce Ecosystem Report in Poland 2025, she revealed her favourite interview question – and it’s worth taking notes, especially if you’re thinking of applying to Craftware. Beyond this clip, we also covered some really important topics: ✨ The growing role of women in the Salesforce ecosystem ✨ Inclusion, mentorship, and leadership at Craftware ✨ Bridging aspirations and reality when it comes to skills development 📺 Watch the full LinkedIn Live here: https://lnkd.in/dktE9fRg 📄 Get your free copy of the Salesforce Ecosystem Report 2025 here: https://lnkd.in/daF57YM7 Huge thanks to Craftware for their support in making this report a reality and for helping drive the conversation forward! 🙌 Adam Barański Łukasz Chęciński #Salesforce #SalesforceEcosystem #SalesforcePoland #Leadership #Inclusion #FutureOfWork

71

2 komentarze

20 Salesforce architects. 1 complex challenge. Only 10% got it right. The difference? They didn't jump to a "safe" technical solution. The 10% who succeeded used DSQ—perfect for whiteboard sessions and CTA exams when details are scarce but complexity is high: - Distill - Cut through noise to find the essence - Simulate - Decompose and model the solution - Quantify - Reveal the real impact DSQ is just one framework we teach. Master them all in our October CTA cohort (starts 10-OCT) 👇 Link in comments 🔔 Follow me for more weekly challenges to level up your architect skills #salesforce #salesforcearchitects #JourneyToCTA

50

1 komentarz

Finally! You can now test what breaks — not just what works — in Salesforce Flows. For years, Flow testing meant one thing: “Did it run successfully?” But now, Salesforce is flipping the script. With Summer ‘25, there’s a new Flow Test operator: ❌ “Has Error” And that changes everything. No more guessing whether your failure paths are working. No more hoping your automation handles errors gracefully. Here’s what this update means: → Validate negative scenarios (finally!) → Ensure your Flows fail when and how they should → Add assertions that test Create, Update, Delete, and Action outcomes → Improve your automation resilience (and sleep better) Admins, Devs, Architects — this one’s for you. No more blind spots. Just bulletproof automation. Will this change how you test? Drop your thoughts below. #Salesforce #Summer25 #FlowBuilder #AutomationTesting #SalesforceAdmins #CRM #DevLife

143

19 komentarzy

Are you overpaying for Salesforce licenses? In nearly every salesforce audit I run, I find this issue: Everyone has a standard Salesforce license — even when they don’t need it. But Salesforce offers different license types for different use cases and different editions: Some users only need to run reports or update a few fields in select objects. Others don’t need access to Opportunities or Campaigns. In many cases non human integration accounts are taking standard licenses when an integration license will do. One recent client was able to save significant funds just by matching users to the right license type for their role. It’s an easy win that often gets overlooked.

71

22 komentarze

𝗙𝗹𝗼𝘄 𝗶𝘀 𝗻𝗼 𝗹𝗼𝗻𝗴𝗲𝗿 𝗮 𝗯𝗮𝗰𝗸𝗴𝗿𝗼𝘂𝗻𝗱 𝘁𝗼𝗼𝗹. It has been in the spotlight for quite some time now and is on the verge of becoming something much BIGGER. I just read an insightful interview with Adam White, Product Manager at Salesforce, and one thing is crystal clear: Flow has evolved from "𝘯𝘪𝘤𝘦-𝘵𝘰-𝘩𝘢𝘷𝘦" to "𝘮𝘶𝘴𝘵-𝘶𝘴𝘦" for anyone working declaratively on the platform. 𝗧𝗵𝗲 𝘀𝗵𝗶𝗳𝘁? Customers are now asking: "𝘏𝘰𝘸 𝘥𝘰 𝘸𝘦 𝘤𝘰𝘯𝘯𝘦𝘤𝘵 𝘰𝘶𝘳 𝘵𝘰𝘰𝘭𝘴 𝘵𝘰 𝘍𝘭𝘰𝘸?" instead of the other way around. That's a game-changer. Flow Is Becoming Foundational This changed with the retirement of Workflow Rules and Process Builder. Suddenly, Flow wasn't just an option; it became the option. 𝗪𝗵𝗮𝘁'𝘀 𝗖𝗼𝗺𝗶𝗻𝗴 𝗡𝗲𝘅𝘁 Action Hub (still in beta) gives you a central place to manage custom invocable actions across your org, invaluable for orgs with complex automations and multi-admin teams. Salesforce is also pushing toward enterprise-grade capabilities: siloed test data, better collaboration tools, stronger governance, and monitoring. Flow is on the way to making itself as powerful and reliable as Apex, only more approachable to admins and without the barrier of code. Here's Where It Gets Interesting 𝗔𝗱𝗺𝗶𝗻𝘀 𝗮𝗿𝗲 𝗱𝗿𝗼𝘄𝗻𝗶𝗻𝗴 𝗶𝗻 𝗙𝗹𝗼𝘄 𝘄𝗼𝗿𝗸. We've been tracking this at Clientell: 57% of all tasks performed through our AI agent revolve around Flows, migrating Process Builder/Workflow Rules, building complex new Flows, or troubleshooting/updating existing ones. That's validation that admins need intelligent help exactly where Salesforce is doubling down. 𝗔𝗻𝗱 𝘆𝗲𝘀 𝘁𝗵𝗲 𝗳𝗹𝗼𝘄 𝗶𝗻 𝘁𝗵𝗲 𝗶𝗺𝗮𝗴𝗲 𝘄𝗮𝘀 𝘃𝗶𝗯𝗲 𝗰𝗼𝗱𝗲𝗱 𝘂𝘀𝗶𝗻𝗴: app.clientell.ai Our goal with AI in Flow has been to embed it where it can make a real difference, freeing admins from some of the most time-consuming and manual parts of Flows and letting the AI agent handle it. You think, and it does it for you. The message for admins and architects is clear: if you haven't already, now is the time to double down on Flow because it's no longer just one option in the toolbox; it's become the toolbox itself. #salesforce #agentforce #SalesforceAdmins #Flows #AI

71

1 komentarz

The Project Overview: The Architect’s Anchor in Every Salesforce Initiative If you’re preparing for the Salesforce CTA Review Board—or leading any major Salesforce implementation—the Project Overview isn’t just a slide. It’s your anchor. It sets the stage for your architectural narrative, aligns stakeholders, and showcases your ability to balance business goals with technical execution. But more importantly, it proves that you're not just designing systems—you're leading transformation. Too often, we see architects dive into technical deep-dives without first clearly framing why the solution exists, who it serves, and what success looks like. And with constant updates, shifting priorities, and fast-paced delivery, it’s easy to skip this step. But that’s exactly why it matters so much. Even with tools like ChatGPT or the best agile boards, keeping yourself and your stakeholders truly aligned is tough. The Project Overview is where that alignment starts—and continues. It helps you avoid scope drift, justify design trade-offs, and stay connected to business value. Checklist: What to Include in Your Project Overview Slide 1. Client Introduction Industry, size, global presence Key business characteristics 2. Current Situation Existing systems and Salesforce footprint Known pain points 3. Project Goals Business and technical objectives Success criteria (e.g., increase CSAT, reduce TCO) 4. Business Challenges Operational inefficiencies e.g. Data silos, compliance gaps, scalability limits 5. Scope Geographies, business units, user types Clouds in scope (e.g., Sales, Service, Experience) Integration, migration, decommissioning 6. Key Requirements & Constraints Regulatory or legal Timeline, budget, legacy dependencies 7. Stakeholders Business and technical personas Key decision-makers and users 8. Strategic Drivers Digital transformation, customer centricity, cost efficiency For Salesforce Architects, the Project Overview isn’t just the beginning. It’s the compass. Use it to drive clarity, structure your decisions, and bring your audience—CTA judges, business sponsors, or delivery teams—on the journey with you.

49

6 komentarzy

I spent four evenings with Clean Apex Code - and it was absolutely worth it. A must-read for any Salesforce developer or architect. The book offers practical, real-world guidance on writing clean, testable, and maintainable Apex code. Clear, practical, just solid principles and actionable examples. So good to see someone finally put this all together in one place. Based on the one of the first sentences, the book seems to be aimed at developers with at least 5 years of experience - don’t listen to that. If you’ve been working with Apex for a year or two, you should be able to read it with understanding, and it will save you from making tons of avoidable mistakes. It’s one of those books worth revisiting regularly, because you’ll find something new with every iteration. I especially loved the chapter about unit tests. I also believe that behavioral tests make the most sense in many cases, and no one should fear or hate integration tests - these are the tests that truly make your system stable. Good job, Pablo Gonzalez 🇨🇷! 👏 Putting together years of best practices, code patterns, and testing philosophy into such a concise and readable book is no small task. This is a great contribution to the Salesforce developer community! #salesforce #architecture #cleancode #apex

596

12 komentarzy

🔥 Best Place to Work for Salesforce Architects – The Consulting Path 🔥 I’m often asked: “What’s the best place to grow as a Salesforce Architect in consulting?” Rather than naming companies, I’d like to offer a framework based on the five phases many architects go through in their journey. This isn’t one-size-fits-all—but it might help you find direction. 1️⃣ Exploration Phase – Try Everything At the beginning, you’re figuring things out. 👉 Try different roles, industries, technologies, and clients. This helps you learn what consulting really means—and whether the architect role suits you. ➡️ Small to mid-sized consultancies are usually best at this stage: more flexibility, more exposure. 2️⃣ Foundation Phase – Build Skills & Identity You’ve chosen the architect path—now build depth and range. 👉 Get hands-on across multiple Salesforce products. 👉 Learn whether you’re a specialist or generalist, technical or business focused. ➡️ Mid-sized consultancies often offer the ideal balance of complexity and autonomy. 3️⃣ Leadership Phase – Lead & Influence You’re now leading other architects, managing stakeholders, and shaping initiatives. 👉 Leadership, communication, and strategic thinking become key. ➡️ Mid to large consultancies support this evolution with bigger teams and more visibility. 4️⃣ Strategic Phase – Architect at Scale You’re running multiple programs, driving change through influence—not execution. 👉 You enable transformation by aligning architecture with business strategy. ➡️ Large consultancies with enterprise clients and long-term programs are your playing field. 5️⃣ Entrepreneurial Phase – Build or Sell You’ve mastered delivery and strategy—now you’re ready to shape the business itself. 👉 Start your own consultancy, productize your expertise, or pivot into a commercial or sales leadership role within an established consultancy. Your value now lies in relationships, brand, and business vision. ➡️ This phase is about independence and impact. You choose the platform. ❗️This is a directional guide—not a rulebook. Everyone’s path is different, but I hope it gives clarity to those asking: “Where should I go next in my Salesforce consulting journey?” ❗️ This is an updated version of my post from a year ago—refined stages and a new fifth step added. Hope you found it useful and insightful! #SalesforceArchitecture, #SalesforceCareer, #SalesforceConsulting

96

16 komentarzy

In the Salesforce Winter ’26 release, a new Flow Comparison feature is being introduced that allows you to select and compare two versions of a flow side by side. This makes it much easier to spot changes between versions. The feature supports Record-Triggered, Scheduled, and Auto-Launched flows. Screen flows are not included yet. For more such content, keep following Salesforce Geek #Salesforce #Winter26 #Flows #Salesforcegeek

258

1 komentarz

The Winter ‘26 release notes were live last week, and there are some new and exciting features for Salesforce Developers – from “Trusted Mode” and Flow testing with CLI. Peter Chittum explains more about the most relevant updates that devs will want to get their hands on. #Salesforce

234

8 komentarzy

So many Salesforce flows. Multiple orgs. A mountain of documentation to create. So little time. Sound familiar? It doesn't have to be this way. Here's how I solved it: Downloaded Metadata with Salesforce Inspector - Used Salesforce Inspector to efficiently extract all necessary metadata directly from our systems. Processed with ChatGPT- Sent the metadata to ChatGPT, prompting it to tailor the information precisely for my target audience: admins, devs, and end-users. Eliminated Manual Effort - This method allowed me to bypass countless hours normally spent taking screenshots and manually typing up documentation. This approach not only saved me hours but also significantly improved the accuracy and relevance of our documentation. Plus it gave me back some time to make this video 😄 Curious about the specifics or want to share your own challenges? Let’s dive deeper! #Trailblazers #Salesforce #AwesomeAdmins

55

14 komentarzy

🚨 What are the responsibilities and skills Salesforce architects should have? Since I focused my career on the #role of #Architecture within the Salesforce ecosystem, I have observed something very clear: there is a lot of doubt and misunderstanding about what this role really entails. Many times, it is assumed that the architect is simply a “Senior Consultant” or someone who supervises from afar without getting directly involved with the #teams. But the reality in #Salesforce is very different. The role of #Architecture in #Salesforce goes far beyond technical expertise or years of experience. It is a strategic function that aligns #business #goals, #technology #capabilities, and cross-functional #teams. A #Salesforce #Architect drives value through three core responsibilities: ✅ #Strategic #Design: crafting scalable, secure, and sustainable solutions that align with long-term business objectives. ✅ #Technical #Governance: defining standards, enforcing best practices, and ensuring platform integrity across teams and projects. ✅ Cross-team #Enablement: bridging the gap between business and delivery teams, guiding implementation, and ensuring every solution fits within the broader #ecosystem. What many fail to see is that a #Salesforce architect actively collaborates with Salesforce Developers, Salesforce Admins, functional #consultants and #business stakeholders. He or she is not above, but among the teams, connecting dots, #resolving #technical conflicts, and easing the way for solutions to not only work, but make sense over time. #Understanding this role well is not only important for those who aspire to be architects, but also for organizations that want to truly leverage the strategic value that Salesforce can deliver. Compiling articles by Salesforce Ben detailing the role I found the following articles that I like very much: ✅ By Luke Potter: https://lnkd.in/eEjA3Y5s ✅ By Tom Bassett https://lnkd.in/eCj3TS42 ✅ By Salesforce https://lnkd.in/eDFnRP43 ✅ Of course from the AMAZING Gemma Blezard https://lnkd.in/edGcCZCN If you have other opinions, experiences, articles, it will be a pleasure to read or listen to you 💕 #Trailblazers #Salesforce #Ohana

312

1 komentarz

I was recently told that many Salesforce teams cannot refactor their code base because they don't have a ticket to do the refactoring. In my opinion, this is fallacy and another example of how we let the business control too much how we engineer our work (see yesterday's for another example). Unless you work for a highly regulated industry where every line of code must be audited, then you should be able to refactor your code freely and just include the refactoring in the commit of a related feature. Suppose that you are implementing a new requirement and while doing so you realise some part of the code that is adjacent to it could be enhanced for readability, testability or something else. You should be able to simply refactor the code and include that change as part of the commit for the original requirement. "But what if we break things?" I hear you say. That's what unit testing and a QA team are for. You do not need a product or project manager's approval to do small refactorings.

182

36 komentarzy