Salesforce Administration

Hello #Connection #SalesforceInterview #Question #2025 #Question: You have a high-volume Salesforce org where millions of records are processed daily. Your team notices performance issues with triggers, batch jobs, and integrations. How would you analyze and optimize the performance of these components while ensuring scalability? #Expected Answer: To optimize the performance of a high-volume Salesforce org, I would take a multi-layered approach, addressing triggers, batch jobs, and integrations separately while ensuring overall scalability. 1. Trigger Optimization: Bulkification: Ensure all triggers handle bulk operations using Trigger.New, Trigger.Old, and Maps/Sets for efficient processing. One Trigger per Object: Implement a Trigger Handler framework to centralize logic and prevent recursion issues. Use Asynchronous Processing: Offload heavy processing (e.g., API calls, complex calculations) to Queueable, Future, or Batch Apex. Selective Queries & Indexing: Use indexed fields, WHERE clauses, and avoid full table scans. Leverage Skinny Tables if necessary. Avoid DML inside Loops: Batch DML operations to avoid exceeding limits. 2. Batch Jobs Optimization: Reduce Query Load: Use incremental processing (query only new/updated records). Implement Selective SOQL filters using indexed fields. Tune Batch Size: Experiment with scopeSize (e.g., 200 for optimal performance). Monitor governor limits via Limits.getDMLStatements() & Limits.getQueryRows(). Parallel Processing: Use Queueable Apex or Parallel Batch Jobs for non-dependent operations. Implement Chaining but avoid overloading Queueable limits. Use Platform Events or CDC (Change Data Capture): For real-time processing instead of polling-based batch jobs. 3. Integration Performance (APIs & External Systems): Optimize Callouts: Use Continuation (for LWC) or Queueable (for Apex) for long-running external API calls. Implement caching (Custom Settings, Platform Cache) for static data to reduce API calls. Governor Limits Management: Reduce API calls by batching requests (e.g., Composite API, GraphQL). Use Asynchronous Apex (Future, Queueable) for non-critical operations. Streaming APIs for Real-Time Data: Implement Streaming API, Platform Events, or Pub/Sub API instead of periodic polling. 4. Monitoring & Troubleshooting: Apex Execution Logs & Debugging: Analyze logs using Event Monitoring, Apex Replay Debugger, or Log Analyzer. Use System.debug(Limits.getHeapSize()) to check memory consumption. Performance Monitoring: Use Salesforce Optimizer, Lightning Usage App, and Einstein Recommendations. Enable Debug Logs, Governor Limits Monitoring, and Transaction Security Policies. Query Performance: Run SOQL queries in Developer Console to check execution time. Use Query Plan Tool to identify indexing needs.

10 steps guide to know what you don't know about your Salesforce org Most businesses using Salesforce don't know what they don't know about their org. Especially when it's up and running for a couple of years already. Ignoring issues and "sweeping them under the carpet" can come back to bite you when you least expect it... Here’s a 10-step guide to auditing your org and gaining a comprehensive view of your Salesforce environment: 1. Records Sharing Model → Who can access your most sensitive records? → Review central and sensitive objects. Ensure they're not set to "Public Read/Write", unless that's what you intended it to be! → Is access managed through a role hierarchy? Verify if role hierarchy is used and properly implemented. 2. Salesforce Optimizer → Run Salesforce Optimizer for actionable insights on system performance. → You’d be surprised by how many insights it can provide! 3. Health Check → Are your security settings optimized? → Use Salesforce "Health Check" to identify and optimize security settings. → You can change the "Baseline" to your own needs if needed. 4. Access & Security → Which third party has login access? → Are there org or profile IP restrictions? → Is MFA (Multi-factor Authentication) enabled properly? or is it bypassed? → Are your connected apps secure? Remove old and unnecessary integrations, and review the active apps settings. 5. Limits and Data Storage → Are you nearing your limits? → Under "Company Information", check data and file storage usage. → Identify the most consuming objects. →Is your data backed up? At a minimum, use the Salesforce weekly export tool, or consider tools like OwnBackup or Salesforce Backup. 6. Fields usage → Are your fields being used? Use Field Trip to analyze field usage in the main objects. → Are your fields classified? check how many fields have Metadata fields populated 7. Licenses → How are your licenses being utilized? → Review license usage and identify inactive users (e.g., those not logged in the past 30 days). 8. Profiles and permissions → What profiles are being used? Check which profiles are assigned to users → What permissions do those profiles have? Review and plan to transition to permission sets. → Do you have the right number of admins? Ensure only necessary users have admin privileges. 9. Process Automation → Are you carrying technical debt? Time to migrate to Flow— map how many Process Builder and Workflow Rules are still active 10. Release Updates → Are you up-to-date with Salesforce releases? → Review and enforce relevant Salesforce release updates → It only takes one ignored update to cause significant trouble! Ready for a health checkup? Reach out for a comprehensive Salesforce org audit.

Do you still write everything in Synchronous Apex? If yes, you’re probably hitting governor limits way too often 🚨 💡 Here’s the truth → Real Salesforce projects survive only because of Asynchronous Apex. 👉 Think about it: Fetching millions of records? → Batch Apex. Doing a payment gateway callout from a trigger? → Future method / Queueable. Running nightly jobs to clean data? → Schedulable Apex. 🔥 My Golden Rule for Interviews & Projects Use Future when it’s a simple fire-and-forget job (like callouts or avoiding Mixed DML). Use Queueable when you want chaining, job tracking, or complex data passing. Use Schedulable when timing matters (run it at 2 AM every day 🌙). Use Batch Apex when you’ve got millions of records and need Salesforce to chunk them. 🔗 Resources (for serious prep): 👉 100 Scenarios (1–4 YOE): https://lnkd.in/gvRbaChu 👉 100 Scenarios (4–8 YOE): https://lnkd.in/gHpeRAqa 👉 LWC Q&A (Explained): https://lnkd.in/gHwiZeGK 👉 600+ Recruiter Calls Qs: https://lnkd.in/gFs-CkxT 👉 TCS, Infosys, EY Qs: https://lnkd.in/gsATfUk3 👉 Salesforce Mega Pack: https://lnkd.in/gHjG5TVU 💻 Example: I once had to process 1.2 million Account records for a client. ✅ Batch Apex + Database.Stateful saved the day — we cleaned data in chunks while preserving progress between batches. The client thought it was magic. For me, it was just the right choice of Asynchronous Apex. 🚀 🎯 Takeaway: Synchronous is easy. Asynchronous is scalable. If you want to ace interviews and build enterprise-grade Salesforce apps → Master Asynchronous Apex. 💬 Which one do YOU use most — Future, Queueable, Schedulable, or Batch? Drop your go-to choice below 👇 #Salesforce #Apex #AsynchronousApex #BatchApex #QueueableApex #FutureMethods #Schedulable

Scratch orgs are temporary, disposable Salesforce environments introduced with Salesforce DX. Unlike 'permanent' development sandboxes, scratch orgs are designed to be lightweight, customizable, and relatively short-lived - perfect for development and testing in rapid iteration cycles - and perfect for large enterprise projects. Sounds like a no-brainer? Why are still projects struggling with the adoption? A few observations: 1) The scratch org definition file doesn't accurately reflect the development needs - specify edition, features, settings, and preferences in your definition file. This is rather a manual process to find here the right approach. 2) Packages that need to be installed are left out. Ensure to have everything in place. There is plenty of room to be innovative - for example, creating scratch orgs during a nightly job and making them available "off the shelf" to developers - this can be beneficial if you have plenty of packages that need to be installed. 3) A lot of manual effort during the development while test data is missing. For us, it turns out to be providing scripts that populate a dedicated set of test data set to make life easier for the development team. 4) Dealing with Salesforce metadata is tricky. We use dedicated scripts to provide the right metadata for a Scratch Org when developing a new feature - from creating the Scratch Org, installing packages, deploying global value sets, deploying metadata from the appropriate long-lived branches, to installing test data and pipeline updates - all covered in a dedicated job. No doubt - finding a proper setup takes effort, but it pays off in the mid- and long-term, while developing new features is much easier, and you have fewer merge conflicts to solve 😉.

Just published a walkthrough of the new Salesforce Go experience for Revenue Cloud. The one-click experience does significantly cut down a large chunk of the manual configuration work we normally have to do in fresh environments. I tested it in a new org and Salesforce Go automatically handled the entire foundation: enabling Revenue Cloud, Quotes, Orders, Product Configurator, turning on Context Service, extending the Sales Transaction and Product Discovery context definitions, activating Salesforce Pricing, generating all the default pricing procedures, selecting them, and even activating the Standard Price Book. If you’ve ever set up Revenue Cloud from scratch, you know this can easily take half an hour or more so this accelerates setup in new environments. There’s still plenty of configuration that follows: products, price books, pricing rules, templates, approvals, and your broader implementation work. But as a starting point, this significantly accelerates the setup phase and ensures no foundational steps are missed. Full video is now live. Happy to answer questions or go deeper into the underlying structures like context definitions and pricing procedures for anyone implementing Revenue Cloud.

🔑 Managing Access in Salesforce Just Got Easier As Salesforce orgs grow, one of the trickiest parts of an admin’s job is managing who gets access to what. Relying only on profiles, permission sets, and manual updates often leads to confusion, security risks, and wasted time. That is where User Access Policies come in. Think of them as a traffic signal for access: you set the rules, and Salesforce automatically grants or revokes permissions when user attributes change. A new Sales Rep joins? They can be instantly assigned the right permission set group, public group, and licenses with no manual steps required. 😎 Why this matters: -Consistency: Every new hire gets the right access immediately -Less Admin Overhead: No more chasing down permission requests -Stronger Security: Old access is removed automatically -Audit-Friendly: You can point to clear, rules-based policies But automation is only as good as the data behind it. It's recommended to test policies in a sandbox first, so you can validate rules, check for data issues, and avoid accidental permission chaos in production. ✅ Best practices: -Start small with one team or department -Document your rules -Review quarterly to avoid permission creep -Always test in a sandbox before rollout User Access Policies do not replace everything such as profiles or complex flows, but they add a solid automation layer to keep your org secure and consistent. #SalesforceAdmins #SalesforceDevelopers #Salesforce Image credit: Salesforce Trailhead

We've all encountered it, or perhaps even inherited it: the Salesforce org that's become an unmanageable "Big Ball of Mud." It's easy to blame sloppy coding, but often the root cause is deeper—a gradual decay of architectural integrity over time. Think of it as the second law of thermodynamics applied to software. Every change, every quick fix, every workaround adds a tiny bit of disorder. Without active counter-measures, this disorder, or entropy, accumulates. The solution isn't just to "clean up the code" once in a while. It's about embedding continuous architectural attention into your development process. This means: • 𝗥𝗲𝗴𝘂𝗹𝗮𝗿 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗮𝗹 𝗿𝗲𝘃𝗶𝗲𝘄𝘀: Not just code reviews, but assessments that specifically evaluate the overall system structure and dependencies. • 𝗥𝗲𝗳𝗮𝗰𝘁𝗼𝗿𝗶𝗻𝗴 𝗮𝘀 𝗮 𝗵𝗮𝗯𝗶𝘁: Make refactoring a continuous activity, not a "big bang" project that happens once a year (or never). • 𝗦𝘁𝗿𝗼𝗻𝗴 𝘁𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗴𝗼𝘃𝗲𝗿𝗻𝗮𝗻𝗰𝗲: Establish clear architectural guidelines and enforce them consistently. • 𝗙𝗶𝗴𝗵𝘁𝗶𝗻𝗴 𝗳𝗲𝗮𝘁𝘂𝗿𝗲 𝗰𝗿𝗲𝗲𝗽: Every new feature request should be evaluated not just for its business value, but also for its impact on overall system complexity. Architectural entropy is inevitable, but it's manageable. The key is to be proactive, not reactive. Want to learn more about preventing architectural decay and other common Salesforce pitfalls? Check out "Salesforce Anti-Patterns" for practical strategies and real-world examples. 

I don’t believe in “You need 50 different permission sets.” Most admins don’t create chaos on purpose. It starts with good intentions, least privilege, one-off requests, edge cases. But a year later: • Nobody knows what each set actually does • Field access issues become weekly support tickets • And audits? Like diffusing a bomb... blindfolded Here’s what’s worked for us—simple steps, real tradeoffs: 🔹 Start with a baseline cleanup Audit everything. Manually, or with tools like Hubbl Technologies. Kill the one-off sets from “that one Q3 campaign” in 2021. → One mid-size org cut 52% of their permission sets and halved audit prep time. 🔹 Use Hierarchy Custom Settings You don’t need a new set for every edge case. We tied access to team, region, or deal thresholds. → In one financial client, anything under $1M now auto-approves—no manual review. 🔹 Bundle smarter, not more Permission Set Groups work. But muting and expiration? That’s the real unlock. → A telecom client dropped onboarding time from 45 minutes to just 5. 🔹 Build for 2026, not tomorrow Profiles are losing object/field permissions by Spring ’26. This isn’t optional. And rushing later = regret. → Start bundling now. Save your future self the scramble. 🔹 Let AI handle the leftovers Set alerts for any “View All” sneaking in. Auto-flag anything unused after 90 days. → One client reduced SoD violations by 3x. Why? Because most permission issues aren’t technical—they’re just forgotten. Old projects. Past hires. Temporary fixes that stuck around. Clean once. Automate the rest. Then stop thinking about it. Real question: What’s the oldest permission set still active in your org? (I once found one last touched in 2017. Still assigned to 14 users.) Sal Dhaka Mike Bogan Clientell Hubbl Technologies #Salesforce #RevOps #SalesOps #AIAgents #PermissionSets #Hubbl #Clientell

Cloning System Administrator profile: Worse than adding more system admins “How is it these users can delete data?” “It’s in the profile we assigned them” “Why is it in the profile to begin with?” “Not sure. We’ll remove it” A few weeks later … “How is it these users can delete data?” “It’s in the profile we assigned them” “Why is it in the profile to begin with?” “I’m getting that déjà vu feeling” “What? Why?” “This happened last month” “No. Those were different users” This is worse than just assigning the standard System Administrator profile to them—a big no-no to begin with Reason: you easily lose track of which profiles have elevated permissions View All Data Modify All Data Author Apex Manage Certificates … That has security risk written all over it Best practice for a new app or group of users is to start with the minimum access profile and add only the permissions needed for them to do their work It’s even better to add those permissions in one or more Permission Sets because eventually Salesforce won’t allow them in Profiles anyway So first, make sure that those users who have System Administrator are actually real system administrators—and are accountable to what that role means when it comes to security And secondly, don’t clone and rename the System Administrator profile and call it something else. That just gives users privileged access who shouldn’t have it—and makes real system administrators’ jobs harder by trying to figure out who those users are