Skip to main content

Posts

Showing posts with the label Salesforce

Two arguments for a single-org strategy and one for multi-org

Photo by Direct Media on StockSnap It was a general catchup meeting with a stakeholder, we discussed about the health of their salesforce, about how different teams are doing and then the stakeholder mentioned something that made my ears standup, "We have audited our instances and turns out we have 5 Salesforce Org, what do you think is ideal?" A deep breath. This question has come up more than once: the bigger the organization, the more complex the question gets; we discussed the health of their salesforce and how different teams are doing, and then the stakeholder mentioned something that made my ears stand, "We have audited our instances and it. Many years ago, I was asked to look into an client with close to 8 Salesforce instances. One was just there to work on Ncino, and the rest were customized by different regions according to their needs. But when we analyzed the business model of all the regions, they were doing the exact same thing with different configurati...

An algorithm to make the perfect coffee

The warm aroma of freshly brewed coffee fills the air, and as I take my first sip, I can't help but feel a sense of calm wash over me. The world outside is still and quiet, as if it's holding its breath, waiting for the hustle and bustle of the week to begin. You take a moment to reflect on the past week and set intentions for the weekend ahead while enjoying your coffee. It's a small yet meaningful ritual that sets the tone for the rest of your day. It's Friday after all. A fellow developer had recently commented, "Why do I need to know about maps and sets? Flows will do most of the job for us..." Why must we study programming fundamentals when we have a very powerful platform like salesforce focused on less or no code? And that is where the sip of beautiful coffee mingled on the tongue, and an answer came to the fore. We get so many good coffee machines in the market, then why do we need to learn how to make filter coffee? We get amazing pod machines, profes...

Let's settle the debate between Custom Metadata, Custom Objects and Custom Settings

This is a common scenario in any design meeting. First, you have the one person who recommends using Custom Metadata for something that clearly should be a Custom Object. But custom metadata can be deployed using the release pipeline, and it's easy. Why do we create too many custom objects? Knowing the purpose behind these features is essential to use them effectively. Let's start with custom settings. These bad boys are like the steroids of your application, allowing you to store information such as default values, external service endpoints, or other data that needs to be accessed at warp speed. Thanks to custom settings being cached in memory, they're always ready to go when needed. Plus, they can be accessed by Apex classes, Visualforce pages, and formula fields, making them the perfect tool for storing data that needs to be accessed quickly. Next up, custom metadata types. These are like the blueprints of your application, allowing you to control your application based...

Chatbots: The future of customer service?

I have been spending a lot of time trying to remodel and train a chatbot, trying to make it as human as possible. The model is not without flaws, event though I have collected a lot of intents from Amazon. This was the presentation I gave on the topic at the London DUG. And to see the chatbot follow this link: https://awesomesid-developer-edition--builder.um5.force.com Note: Order number: 00001- 00011 Scenario: Your order is lost or you have not yet received your order.

Have you met the Ghost Records of Salesforce?

This post is very old but it is long overdue. Have you seen the Ghost records in Salesforce? Whenever there is an auto-number field on an Object, it suddenly seems to have gaps in between? For e.g., if you have a auto-number set at 00001 and the next record it creates is 00004. These gaps are sometimes attributed to people who create records and delete. Auto-number fields Lets talk a bit about auto-number. Apart from the part that they are cool, they are also very stubborn. An auto-number field resets only once in its lifetime and never turns back. When an auto-number is incremented it does not go back, even if the record is deleted. So when you delete a record that has auto-number field on it, it will not decrement it by 1 but instead create the gap. Ghost records The real crux of the issue lies when developers write unit classes. Developers always create dummy records for testing. The test execution runs in a separate context than the main Salesforce. These records are not s...