Tribal Knowledge Every Salesforce Developer Should Know
A preview of the 46 hard-won rules from production Salesforce deployments. The kind of knowledge that takes years to accumulate — available to your AI assistant today.
Nishant Goswami
Every Salesforce developer has a collection of lessons learned the hard way. The trigger that caused an infinite loop. The SOQL query that hit governor limits in production but passed every test. The deployment that broke field-level security because nobody checked the profile assignments.
These lessons aren't in the official documentation. They're tribal knowledge — patterns, anti-patterns, and hard-won rules passed between developers on teams, in forums, and through painful production incidents.
Kognyt MCP Pro includes 46 of these rules, organized into 6 categories. Here's a preview of what your AI assistant learns.
Trigger Patterns (8 Rules)
Triggers are where most Salesforce bugs live. Not because triggers are hard to write, but because the patterns that prevent bugs are non-obvious.
One trigger per object. This is the foundational rule. Multiple triggers on the same object execute in an unpredictable order. One trigger per object, delegating to a handler class, gives you full control over execution order.
Recursion guards are not optional. After-update triggers that modify the same record will re-fire themselves. Use a static boolean or a Set<Id> of already-processed records to prevent infinite loops. This is the single most common trigger bug.
Always bulkify. Your trigger will receive up to 200 records at once in a batch context. If your logic works for 1 record but fails for 200, it's broken. Every query, every DML operation, every callout must work at scale.
Governor Limits (12 Rules)
Governor limits aren't just documentation to memorize — they're the architecture constraints that shape every design decision on the platform.
Never SOQL in a loop. This is the first rule every Salesforce developer learns, and the one that still catches people. You get 100 SOQL queries per synchronous transaction. A loop that processes 150 records with a query each will fail. Query before the loop, map the results, reference the map inside the loop.
CPU time is the invisible limit. You get 10 seconds of CPU time per synchronous transaction (60 seconds for async). Complex string operations, nested loops, and JSON parsing all consume CPU time without hitting any other governor limit. Profile your code.
Heap size matters in batch. Batch Apex gets 12 MB of heap per execute method. If you're processing large records or building complex data structures, monitor heap usage with Limits.getHeapSize().
SOQL & Data (7 Rules)
SOQL looks like SQL but behaves differently. The rules that make SQL queries efficient don't always apply.
Selectivity determines performance, not row count. A query that returns 10 rows can be slow if it scans the entire table. Use indexed fields in WHERE clauses. Custom fields need custom indexes — they're not indexed by default.
Avoid SELECT *. In SOQL, querying all fields isn't just a performance issue — it loads data into heap memory. Query only the fields you need, especially on objects with many fields or large text areas.
Relationship queries have depth limits. You can traverse 5 levels of child-to-parent relationships and 1 level of parent-to-child subqueries. Plan your data model access patterns around these constraints.
Security (6 Rules)
Security in Salesforce isn't optional — it's enforced at the platform level. Code that ignores security will pass tests but fail security reviews.
Always check CRUD and FLS. Before any DML operation, verify the running user has the right permissions. Use Schema.sObjectType.Account.isCreateable() and field-level isAccessible() checks. Code that skips these checks will fail AppExchange security review.
Understand with sharing vs without sharing. Classes without an explicit sharing declaration inherit from their caller. This means the same class can run with different sharing rules depending on who calls it. Always be explicit.
SOQL injection is real. If you're building dynamic SOQL with user input, use String.escapeSingleQuotes() or bind variables. Never concatenate unescaped user input into a query string.
Testing (5 Rules)
Salesforce requires 75% code coverage, but coverage alone doesn't mean your code works.
Test data factories, not inline data. Create a TestDataFactory class that builds valid test records for your custom objects. Every test class should use it. When your data model changes, you update one factory instead of 50 test classes.
Always test bulk. Insert 200 records in your test, not 1. If your trigger works for 1 record and fails for 200, your test should catch that. This is the most common gap between tests and production behavior.
Test negative cases. Don't just test the happy path. Test what happens with null values, empty lists, records the user doesn't have access to, and records that violate validation rules. Production data is messy.
Architecture (8 Rules)
These rules shape the overall structure of your Salesforce application.
Separation of concerns is non-negotiable. Triggers should delegate to handler classes. Handler classes should delegate to service classes. Service classes should be testable without triggers. This isn't over-engineering — it's the minimum viable architecture for maintainable Salesforce code.
Flow vs Apex: use the right tool. Flows are better for simple record-triggered automation, screen-based processes, and admin-managed logic. Apex is better for complex logic, batch processing, integrations, and anything that requires unit testing. Don't write Apex when a Flow will do, and don't use Flows when you need Apex's power.
Error handling is a feature, not an afterthought. Use Database.insert(records, false) to handle partial failures. Log errors with meaningful context. Surface actionable error messages to users. Never catch and swallow exceptions silently.
Using These Rules with Kognyt MCP
These 46 rules are available as a Pro tool in Kognyt MCP. When your AI assistant encounters a Salesforce coding task, it automatically queries the relevant tribal knowledge rules and incorporates them into its suggestions.
You don't need to remember every rule or paste them into your prompt. The MCP server handles the context injection transparently.
To get started:
npx -y @kognyt/salesforce-mcp
The tribal knowledge tool is available with MCP Pro ($9/month). Read the full documentation for configuration details.