Salesforce Development

⚡ 1-Minute Summary The Salesforce platform offers specialized APIs for different workloads. The Composite API bundles multiple REST calls into a single trip. Bulk API 2.0 processes millions of records asynchronously. GraphQL allows front-end applications to query exact data fields to avoid over-fetching. Choosing the wrong API leads to poor performance and hitting governor limits. 💬 In plain words: Three power APIs for three different jobs: Composite API bundles several REST calls into one single trip (e.g., creating a parent and children in one POST). Bulk API 2.0 acts like a freight train, moving millions of rows as background jobs. GraphQL acts like a restaurant menu, letting the caller order exactly the fields it wants with no wasted data. 📌 Example: Need to create an Account + 3 Contacts + 1 Opportunity in ONE API round trip? Use a Composite request with allOrNone=true so it's an all-or-nothing transaction. ...

💬 In Plain Words: Three decorators, three specific jobs. @api makes a property public so the parent component can control it. @track forces a re-render when you change data inside an object or array. @wire automatically pulls data from Salesforce and refreshes whenever its inputs change. Everything else is just a plain field—and remember, plain fields in modern LWC are already reactive!

💬 In Plain Words: Salesforce has three generations of UI frameworks. Visualforce is the oldest (page-per-server-trip). Aura was the first component-based framework, but it is slow and heavy. Lightning Web Components (LWC) is the modern web standard and is vastly faster. The rule today is simple: All new custom development must be LWC. For declarative (no-code) development, use Lightning App Builder to assemble pages, and Dynamic Forms to put fields conditionally on a page without writing code. 📌 The Strategy Example: Imagine your org has a 2014 Visualforce quote PDF, complex Aura components built in 2018, and a brand new business requirement. The Verdict: Keep the Visualforce page (it's still the best engine for rendering PDFs). Leave the working Aura components alone, but freeze them (no new features). Build the new business requirement entirely in LWC. UI migration is a roadmap, not a reckless rewrite.

Importing data in bulk from a local spreadsheet is a standard requirement for many enterprise applications. While tools like Data Loader handle this out of the box, developers often need to build custom, self-service tools that allow end-users to upload and process CSV files directly from a custom page layout. In plain words: You can create a file upload interface using Visualforce, capture the file content as a binary blob, and use an Apex controller to parse the text data line-by-line. The code converts those text rows into Salesforce objects (like Contact records) and inserts them into the database in bulk.

💬 In plain words: SOQL (Salesforce Object Query Language) is used to ask precise questions about a single object and its related records. SOSL (Salesforce Object Search Language) is a broad text search across multiple, unrelated objects at the same time. When writing SOQL, remember this golden rule for relationships: query from a child to a parent using dot notation, and query from a parent to its children using a subquery.

💬 In plain words: Let exceptions bubble up to one central place. Catch them there, and permanently write the error to a custom Log__c record via a Platform Event so the log survives a database rollback. An empty catch block is how errors vanish without a trace—and haunt you in production. 📌 Real-Life Example: The Silent Integration Failure Imagine an integration that fails silently for a week because someone wrote catch(Exception e){} . To fix this, catch the error once at the top level and publish an Error_Event__e carrying the message and record ID. A subscriber then inserts an Integration_Log__c . Now, even if the main transaction rolls back, the rollback can't erase the evidence.

💬 In plain words: Platform Cache is Salesforce's short-term memory layer. You pay the performance cost once to run a heavy query or API call out, and then you store the result. Thousands of subsequent requests can read that stored result in microseconds. Org cache is shared by everyone; session cache is specific to a single user. Golden rule: Cache is a temporary hint, not a permanent database. Always write your code to handle a cache miss.

💬 In plain words: Choosing between Salesforce Flow and Apex is not a matter of personal taste—it is a checklist. Choose Flow for simple, same-record, admin-maintained business logic. Choose Apex for complex data structures, high-volume transactions, advanced integrations, and requirements needing robust unit tests and code reviews. 📌 Example: Flow: When an Opportunity moves to Closed Won , create a single onboarding Task. An admin easily maintains this without code deployments. Apex: Recalculate tier-based commissions across five related objects for 10,000 records in a nightly batch. Complexity, volume, and unit tests dictate code over clicks. 🧠 Checklist Rule: Simple, same-record, admin-owned → Flow. Complex, high-volume, enterprise-tested → Apex. The Architecture Decision Matrix Technical debt in Salesforce frequently comes from choosing the wrong automation tier. Evaluate your business requirements against four ...

In plain words: Apex errors occur when your code encounters an unexpected situation—like reading an unassigned variable (Null Pointer), requesting a record that does not exist (Query Exception), violating validation rules (DML Exception), or hitting multi-tenant resource caps (Governor Limits). Salesforce Apex executes in a strongly typed, multi-tenant cloud runtime. While this architecture guarantees system security and shared resource availability, it also enforces strict execution rules. Encountering exceptions is part of everyday development, but understanding why they happen and how to resolve them defensively makes your code resilient, scalable, and production-ready.

In plain words: A Null Pointer Exception (NPE) happens when your code tries to open an empty box. If a variable or object points to null (nothing) and you attempt to read its fields, call its methods, or get its list items, Apex crashes because there is no data in memory to work with. In Salesforce development, the System.NullPointerException is one of the most frequent runtime runtime errors. Because Apex is strongly typed but initializes unassigned object references to null , any attempt to traverse unpopulated relationships, empty map lookups, or unassigned variables will throw an unhandled exception. Writing defensive, null-safe Apex keeps your applications stable and prevents unexpected transaction rollbacks.

If you’ve spent any time building automation in Salesforce, you’ve probably heard this Golden Rule: "Always update fields on the triggering record using a Before-Save Flow!" It sounds simple enough, but why is this rule so heavily emphasized? What actually happens under the hood when you update a record inside an After-Save Flow instead? Does Salesforce rewind everything back to Step 1? Let’s lift the hood on the Salesforce Order of Execution, break down what happens during a record update in plain English, and look at how to build faster, cleaner automation. The Basics: The Salesforce "Assembly Line" Whenever a user clicks Save on a record, Salesforce doesn't just write the data to a database and call it a day. It passes the record through a strict, multi-step assembly line called the Order of Execution . Here is a simplified look at what happens in order: Loads the record and applies your new field values....

In plain words: When working with API responses in Salesforce, use JSON.deserialize(jsonString, YourClass.class) if you know the exact structure of the incoming data. This gives you a structured Apex object so you can access data easily (e.g., user.email ). Use JSON.deserializeUntyped(jsonString) if the data structure changes dynamically or you only need a few specific fields. This returns a generic Map or List, requiring you to cast values manually. Almost every Salesforce integration involves a common step: an external system sends you a JSON string, and you need to extract its values using Apex. Salesforce provides two primary methods to accomplish this. In this guide, we will break down both approaches with working examples, highlight common developer pitfalls, and give you a simple rule of thumb for choosing the right one.

💬 In plain words: JSON.deserializeUntyped parses raw JSON strings into flexible generic Apex maps ( Map<String, Object> ) or lists ( List<Object> )—eliminating the need to define predefined wrapper classes for dynamic third-party API payloads. In Salesforce development, working with JSON information is a common challenge when integrating with external systems or handling data in a flexible and dynamic way. Salesforce provides a powerful method called JSON.deserializeUntyped that allows developers to parse JSON strings into a manageable format. In this blog post, we'll explore the ins and outs of JSON.deserializeUntyped in Apex, understand its usage, and provide practical code examples to demonstrate its capabilities.

💬 In plain words: Unit testing an Apex REST service marked with @HttpPost requires manually setting up RestContext.request and RestContext.response , populating URI parameters or request payloads, and executing positive and negative assertion tests against database state. In Salesforce, the Apex programming language allows you to create powerful web services exposed to external systems for seamless data integration. A common scenario involves using the @HttpPost annotation within a @RestResource class to accept incoming REST requests. In this post, we'll walk through writing effective test classes for an @HttpPost Apex REST web service, setting up RestContext , and handling positive and negative scenarios to achieve robust code coverage.