New Delhi Salesforce News and Updates: Week #38

In the age of DevOps, we see a major trend towards Continuous Integration (CI) and Continuous Deployment (CD). More and more teams adopt development workflows based on git as their version control system and single source of truth. This move has also never been easier since the introduction of the Salesforce DX toolset.

Salesforce DX also introduced new solutions to move to modular development and a package-based approach, thanks to second-generation packaging and the new org-dependent unlocked packages (Beta).

Unlocked packages are a great way to organize your code and teams when working on custom apps, but they’re not necessarily the best fit for every project.

It’s not always easy to untangle the org and break it down into smaller packages when the initial implementations of Sales or Service Cloud used the production org, or a single metadata folder as the single source of truth (sometimes known as the “Happy Soup” approach, as opposed to the Package Development approach).

When used in combination with source control, the unpackaged development model usually implies that all sources lie in the same git repository. This approach is convenient in terms of dependency management: no need to manage dependencies since everything is in one place.

---

Explore the Salesforce APIs with the Upgraded Postman Collection

In case you missed the original announcement, the Salesforce API collection is a Postman resource that wraps together 200+ request templates for tens of Salesforce APIs (REST, bulk, tooling, metadata…). This open source collection comes with a configurable environment and variables that let you easily authenticate and try the requests on multiple Salesforce orgs with a declarative interface. You can even run it from your browser if you don’t want to install the Postman desktop app. Think of it as a clone of Workbench’s legacy REST explorer with more features.

---

When a user presses save in the user interface, a lot happens in Salesforce – validation rules kick in, triggers are executed, flows are run, assignment rules are executed, and much more. This can all add up to a lot of logic being executed while that user is waiting for the application to respond again. Typically, not all of that logic needs to be ran immediately and can be processed at a later time, increasing the performance of the transaction.

In this blog post, we’ll look at a way to offload some of that logic from the save event with a combination of clicks and code. This way, you’ll have the benefit of being able to build your processes quickly using Flow and your users will have more responsive interactions with Salesforce.

---