Resolving Common Salesforce Project Challenges

If I had 30 days to fix your Salesforce, here’s exactly what I’d do. Most teams “tune” Salesforce forever. If I only had a month with your business, I’d ignore the nice‑to‑haves and focus on 5 things: 1. Map the real process (not the slide deck) - Sit with sales / ops and write the actual steps on a whiteboard. - Rebuild stages and fields in Salesforce to match reality, not what the last partner thought “should” happen. 2. Make Salesforce the single source of truth - Kill parallel spreadsheets for pipeline and “shadow” ops trackers. - Move quotes, contracts and key docs into Salesforce so the work happens in the system, not around it. 3. Strip the friction out of daily use - Cut fields to the minimum viable data needed to move a deal. - Make updating an opportunity, logging an activity or generating a quote a 10‑second job, not a 3‑minute chore. 4. Automate the “moments that matter” - Follow‑ups, handoffs and renewals triggered by stage changes and dates, not memory. - Tasks and notifications go to the right person at the right time without Slack chasing. 5. Give leadership one forecast they actually trust - No more “export to Excel and fiddle with it.” - One dashboard that tells you: what’s closing this month, where deals are stuck, and how accurate your forecast really is. On a recent project, doing this took Salesforce adoption from ~20% to 85% in 6 weeks and moved forecasting from “educated guess” to within 5–10% of reality. Same licences. Same team. Different design. If you’re reading this thinking “we’d fail at least two of these,” comment “BLUEPRINT” or DM me “Blueprint.” I’ll send you a link to book a 15‑minute Salesforce Blueprint call where we’ll: - Score your org against these 5 steps - Identify the biggest leaks in adoption and forecast accuracy - Outline what a focused 4‑week fix could look like for your team No slides. Just me, your Salesforce, and a clear plan to turn it into the operating system it should’ve been from day one.

Last week I presented on a panel at True Blue Blazing. The subject was Lessons Learnt from the worst projects ever.   Many people told us that they would have loved to know more so here is a quick checklist of what to do if you want your next project to succeed.   1. Don’t do it on the cheap Trying to save money by using volunteers, interns, or in-house staff who’ve never touched Salesforce before is the fastest way to triple your costs later. DIY might work for flat-pack furniture, but not for enterprise technology. If you think hiring an expert is expensive, try hiring an amateur.   2. Don’t put all your eggs in one basket The classic “Train the Trainer” trap: one super-user attends training because “everyone’s busy,” and then they leave. Suddenly, no one knows how the system works, and all the process knowledge walks out the door. Spread training across all users. Document everything. Set yourself up for success.   3. Measure seven times, cut once Discovery isn’t a luxury — it’s insurance. Spend time in the problem - don’t jump right into solutions Projects that skip proper discovery and stakeholder engagement end up rebuilding halfway through. Invest the time upfront. It’s cheaper than rework later.   4. Clear ownership When everyone thinks someone else owns it, no one really does. Projects without a captain drift — decisions stall, priorities conflict, and accountability disappears. Assign clear ownership and decision-making authority from day one.   5. Executive Buy-In If leaders aren’t visibly aligned, teams won’t be either. Mixed messages from leadership create confusion and kill adoption. When executives sing from the same hymn sheet, everyone else learns the tune.   6. Check Credentials Choosing a partner or consultant based purely on price is a false economy. Choosing the right implementation partner or consultant is one of the biggest success factors in any digital transformation project. Price does matter, but value, experience, and fit matter far more. Check credentials, reference check as you would an employee, and make sure they have current happy customers who can vouch for them.   The Moral of the Story   Every failed project leaves clues. If you don’t learn from them, you’re destined to repeat them.   Because projects don’t fail — people let them.

Most Salesforce orgs are drowning in technical debt and they don't even know it. Here's the brutal truth: McKinsey found that 10-20% of tech budgets get diverted to fixing technical debt. In Salesforce terms? That's your innovation and GTM budget going straight to firefighting instead of growth. The paradox is real, the more successful your Salesforce implementation, the more debt you likely accumulate. What does Salesforce technical debt actually look like? It's not just messy code. It's: -Unused fields cluttering your objects -Multiple triggers without frameworks -Legacy Process Builders and Flows you're afraid to touch -Hard-coded IDs breaking when you least expect it -Duplicate records making your reports unreliable The compound effect is brutal. Just like credit card debt, technical debt grows exponentially. Developers spend 23-42% of their time firefighting instead of innovating. Performance suffers. User adoption drops. Costs skyrocket. Here's your way out: The CLEAR Methodology 1. Classify - Categorize debt by type and urgency 2. List - Create a detailed inventory 3. Evaluate - Assess cost vs. business value 4. Act - Implement in prioritized phases 5. Review - Monitor and prevent new accumulation Start with quick wins: Remove unused fields. Consolidate duplicate reports. Clean inactive users. These high-impact, low-effort moves build momentum. 2025 game-changer: AI-powered tech debt management Agentforce needs solid clean data and efficient processes. AI tools can now automate code analysis, predict maintenance needs, and suggest refactoring, turning debt management from reactive to proactive. The shift-left principle applies here: The earlier you identify debt, the cheaper it is to fix. Don't wait until your org becomes unmaintainable. What's your next step? Start to audit your Salesforce org today to assess how bad it is. Technical debt doesn't have to kill your Salesforce ROI. With the right strategy, transform your org from a source of frustration into a competitive advantage. What's your biggest Salesforce technical debt challenge right now? Drop a comment and share: - The debt that's causing you the most pain - A solution that's worked for your team - What's holding you back from tackling it Let's turn this comment section into a technical debt solutions exchange. Your experience could be exactly what someone else needs to hear. #Salesforce #TechnicalDebt #SalesforceAdmin #SalesforceDeveloper #CLEAR

I can tell in 10 minutes if your Salesforce hire will fail. Last year, a founder ignored me & learned the hard way. He told me: “We’ve hired 2 Salesforce consultants. Neither of them worked.” He was about to hire a 3rd. And within 10 minutes, I knew what the real problem was. It wasn’t the consultants. It was the setup. Over the last 4 years running a Salesforce firm... I’ve seen this pattern over and over. When projects fail, people blame talent. But most of the time? The warning signs show up before the consultant ever logs in. Here are the 5 I look for: (And how you can avoid them) 👇 1. There’s no clear process If I ask, “How does a hot lead move from marketing to sales?” And the answer starts with, “I think…" That’s a problem. If the process isn’t clear in the business, it won’t be clear in Salesforce. 2. Too many decision makers 6 stakeholders. Conflicting opinions. No final owner. The consultant builds what they’re told. Then someone says, “That’s not what we wanted.” Trust drops. Deadlines are missed. 3. No backlog or priorities Everything feels urgent. So the consultant stays busy… But nothing that creates revenue gets done. If everything is a priority, nothing is. 4. No definition of success Features get built. But no one agreed on the metric that matters. Was this supposed to: – Improve lead response time? – Shorten the sales cycle? – Increase renewal rates? If you don’t define the outcome, you can’t measure success. 5. You hired a builder when you needed a partner A builder does exactly what you ask A partner challenges you Brings industry playbooks Ties work to revenue Most growing tech companies don’t need more configuration. They need alignment, ownership, and clarity. Before you hire another Salesforce consultant, do this first: • Document the process • Assign one owner • Rank your priorities • Pick one success metric • Decide if you need strategy or just execution Prep + fit = results. Skip it, and you’ll keep hiring a 4th… and a 5th. -- If you enjoyed this post, you'd also like my weekly newsletter 👉 https://lnkd.in/gswdmJkW

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

Your Salesforce project is a dumpster fire because nobody defined the scope properly. Just last week, I watched a 7-figure Salesforce implementation implode. The exec team thought they were getting a "complete sales solution" while the implementation team was building to a vague SOW that basically said "make it work." Everyone pointed fingers. Nobody got what they needed. Here's the truth about scoping ANY Salesforce project: • If you can't break it down into clear milestones with specific deliverables, you're not ready to start • If your Admin wasn't involved in scope planning, you've already failed • If you didn't document what's OUT of scope, prepare for endless "but I thought this was included" • If you didn't baseline the original scope, you can't prove scope creep when it happens (and it WILL happen) Scope isn't just paperwork before the "real work" starts. It's the difference between a strategic asset and a money pit. Stop treating Salesforce like a magic box that somehow knows what your business needs without you defining it. The platform isn't broken. Your scoping process is.

Most Salesforce failures don’t come from bad tech. They come from teams skipping step zero. I’ve been inside hundreds of Salesforce orgs. And I can tell you: the root cause usually isn’t the code, the builder, or the platform. It’s the lack of upstream clarity. Before you configure a single field or automation, ask: Do we actually know what success looks like — to the business, the user, and the customer? Here are 3 preconditions I’ve seen in every healthy, high-impact Salesforce implementation: 1. A shared definition of DONE --not just technically functional, but operationally valuable 2. User behaviors mapped before system behaviors-- because adoption isn’t magic 3. A “no by default” mindset for features-- simplicity is a strategy The truth is: most Salesforce orgs don’t need more features. They need more ruthless prioritization. If you’re about to build something new, make sure you’ve earned the right to automate. What’s your step zero before kicking off a Salesforce project? #Salesforce #Trailblazers

The fastest way to kill a Salesforce project? Bad data. The second fastest? Automating chaos. Most teams skip the basics. They apply automation to broken processes. They migrate dirty data. Then wonder why adoption fails. What actually works is simple: 1️⃣ Map your processes 2️⃣ Get real executive buy-in 3️⃣ Clean the data 4️⃣ Then — and only then — build the tech Technology follows clarity. Not the other way around. If your implementation feels stuck, we should talk. You don’t need to rebuild — you just need a smarter sequence. #Salesforce #CRM #Implementation #DigitalTransformation #NonprofitTech #DataQuality

💡 Salesforce Tip + Real-Life Analogy + Team Culture = This Post ✈️ Pilots don’t just fly, WE run checklists. And that’s exactly how I see Salesforce developers should approach deployments. Before takeoff, a pilot doesn't "hope" the wings are on. They check. Every. Single. Time. ✅ Is the package properly validated? ✅ Did the test class cover the new endpoint? ✅ Did we update the permission sets? ✅ Was the Flow debugged in a sandbox, or are we playing production roulette? ✅ And my favorite: did we forget to remove the System.debug('temp') again? As a Lead Salesforce Developer (and a pilot), here’s one lesson I bring from the cockpit to the cloud: Confidence doesn’t come from skipping steps. It comes from mastering them. So here's my challenge to fellow Salesforce teams: Create your own deployment checklist. Stick to it. Own it. Your future self (and your org) will thank you. And yes, document it like you're flying a plane full of clients. Because you are.

I call it the Spaghetti Test. Open Setup. Click Flows. Count how many start with "Copy of" or have no description. That number is your technical debt score. I traced a single record update last quarter that triggered 14 automations across 6 objects. The record saved correctly. It also created 3 duplicate Tasks, sent 2 emails to the same Contact, and updated a Revenue field that a different Flow immediately overwrote. The CEO's dashboard was wrong. Not because the dashboard was broken. Three Flows were fighting over the same field and nobody knew the other two existed. Total time to diagnose: 4 hours at $250 hour. Total time to fix: 20 minutes. The diagnosis costs more than the fix. It always does. The problem is never the automation. The problem is that nobody mapped which Flows fire on which objects. Here's why it gets this bad: Salesforce made Flows powerful and accessible. The governance layer didn't keep pace. Every admin can create a Flow. Almost nobody documents them. Multiple Record-Triggered Flows on the same object don't guarantee execution order. If two Flows update the same field, the "winner" depends on which one fires last, which is unpredictable. The fix is not "rebuild all your Flows." The fix is an inventory. How many Flows do you have? Which objects do they fire on? How many share the same object? Do any update the same field? That inventory takes 2-4 hours. It prevents the $14,000 untangling project. The free Flow Audit Checklist maps every automation by object. Link in comments. The Spaghetti Test: open your Flow list right now. How many start with "Copy of"? How many have no description? Share your count. No judgment. The point is awareness, not shame. #Salesforce #SalesforceAdmin #Data