Chevron Component build in Lightning with Same look and feel as of Salesforce Path in read only mode
Salesforce Path is awesome feature, where you can display picklist value at top of record page and on click, it updates value in Salesforce database. However same solution does not fit in all scenario. Consider situation where picklist field is supposed to be changed by some other process or Integration. Now you don’t want anyone to change it from user interface. Even though you like Salesforce Path to show summary at top of page however it won’t be useful in above scenario.
Because of this, I created a Read Only Path Component in Lightning. I tried to keep same look and feel as of Standard Path component. This component will need only two inputs
Record Id – It would be automatically passed if we use it using App Builder
Field API Name – API name of picklist type of field
Now think about it. Only thing I got is Record Id. How would I know Object Name ? How would I know all picklist values for field name supplied ?
How to use lightningStylesheets attribute to render Visualforce in Lightning Experience Stylesheet
Reason I posted previous blog was to showcase life of Visualforce developer before and after Winter 18. If we want to use same Visualforce in classic and Lightning experience then we had to check theme of logged-in user in Visualforce and render page section accordingly.
How to design a Visualforce page so that It would be displayed properly in classic as well in Salesforce Lightning Experience
This topic was subset of my presentation in Salesforce Boston World Tour 2017. Sometimes we find our-self in situation where custom Visualforce page should be displayed with Old theme in classic but with Lightning theme in Lightning Experience.
If you can convince client to use same user interface in classic and Lightning, then it would be an ideal approach. Even Salesforce displays classic user interface for many setup pages inside Lightning experience.
Parallel execution of browsers in Selenium with the help of TestNG and determining maximum operating capacity of custom code in Salesforce
When we build any custom solution in Salesforce, key is to write an efficient and meaningful Apex test classes for sure. However sometime we may need to test how custom application would behave in maximum operating capacity. Here, I am talking about Load Testing of custom applications built on top of Force.com platform. Recently I needed to push my code to its limit to know how many concurrent users can use it before hitting any governor limits. Quickly I realize that its time to call my friends Selenium and TestNG.
Before doing any extensive stress or load testing on Salesforce, we must need to contact Salesforce support and explain them what we are trying to achieve. More detail available in this official Salesforce blog post.
Using Salesforce ANT Migration toolkit to retrieve and deploy custom metadata types with record. Sample Package.xml and ANT script included.
Most of you must already know that there is new way to control your program behavior in Salesforce with the help of Custom Metadata Types. Previously we were using List Custom Settings to create functionalities like managing Trigger’s On/Off behavior or controlling Integration endpoint URLs. However we were not able to use Migration tools to import export records into custom settings.
So, into the new world of Custom Metadata Types, I used change sets mostly to perform deployments. Recently, I needed to use ANT migration toolkit to retrieve and deploy Custom Metadata Types. I was able to do it however If you ask me, I spent more time then expected.
Received errors like :
package.xml - Entity type: 'CustomMetadata' is unknown
Best Practices for Salesforce Lightning Component. How Lightning Data Service can improve Lightning Component performance and solve inconsistent data problem without writing single line of Apex code. Demo source code, image and slides included.
If you have worked on Visualforce and started playing with Lightning Component, you must have identified one important missing feature, which is standard Controller.
Lets assume a scenario, you have two Lightning Components on Account page. One Lightning Component is used to show some fields and other component is used to edit same record.
Problem 1 :
To achieve this, both Lightning components would invoke Apex method separately at the cost of performance, by issuing duplicate server calls. Below image depicts problem, where multiple Lightning component requests same content by making separate server calls.
Example of using Hierarchy custom settings in formula field, custom button, process builder and workflow rules. Youtube video included.
Avoiding hard coded Ids or values from formula field, custom button, process builder, Workflow rules or Approval process using Hierarchy custom setting is not something new. This idea exists from many years in Salesforce ecosystem. However, some times I have seen developers and admins debating on same question, so though to put a consolidated blog post on same.
Why you should avoid hard coded values or Ids in Salesforce ?
Answer is very simple, maintenance. When sandboxes are refreshed or metadata deployed to different instances, admins would need to change values manually. If we are talking about manual post deployment step, then we are also talking about nightmare of maintaining list of manual post build steps.
Can we use Custom Labels to avoid hard coded Ids / values in Salesforce ?
Technically yes, but I would suggest not to use custom labels in Salesforce to avoid hard coded Ids because of below Issues
Dataloader does not support custom label bulk load / restore / export
Imagine there are 100’s of custom label and it needs to be different for each Salesforce instances. You would be left either with manual step or some external tool which may not be allowed / approved by customer.
Hierarchy Custom Settings to Rescue
If you are from Java / C#, consider Custom setting as resource file. Here, you would store information about your application which doesn’t change frequently and controls behavior of application. There are two types of custom settings
List Custom Setting
This custom setting is equivalent to custom / standard object. We can store values in tabular format.
Hierarchy Custom Settings
This custom setting can be used in formula field, process builder, custom button, Workflow rules or Approval process.
Most unique feature about Hierarchy custom setting is that we can have different values at Organization level, profile level and user level.
Custom setting can be used in formula fields using global variable $Setup. Syntax to use custom setting is
Highest priority is given to value defined at user level then profile and at last organization level.
How to show Lightning component on public sites without need of user authentication
I have posted few articles on Lightning Out. In this post, we will see how Lightning components can be displayed on public website. To access these Lightning components, users don’t need to login to Salesforce.