Salesforce: Some Insights

I'm sure as everyone is diving into lightning components development, they are getting acquainted with the nuances of the Lightning components framework. As well as, its current limitations. Being a new framework, this is bound to happen. Although we have our users still using salesforce classic, we have started using lightning components framework our primary development platform and Visualforce is considered primarily for rendering lightning components within Classic Service console. Recently, while re-architecting a critical module, we encountered a problem wherein we needed to generate PDF from lightning components. Now, being Javascript intensive framework, it has limited room for such features (may be included in future roadmap). As of now, there is no native feature within the lightning framework to do so (at least I didn't find anything). Common Scenario - Create Visualforce page to retrieve data and generate PDF For scenarios where the data exist within Sa...

Much has been written and presented around Salesforce single organisation and multi-organisation strategies. But, still the question is asked quite frequently. There are really good articles and blogs and I'm hereby trying to compile the information and add my views to it, to provide a summary. Single Org. Approach In a single org. approach, an organisation maintains one single Salesforce org. all their required operations (planned to be executed via Salesforce) are executed via same org. Ideal for: Small and Medium Businesses Pros Less environment maintenance overhead Uniform processes - a very good opportunity for organisations which want to implement uniform processes/ functionalities across all units Easier user provisioning - once a user is setup, they have access to required functionalities Cons Complicated processes as organisation grows larger and include various operations/ geographies Increased application conflicts - with same processes being used...

With more and more complex components being built into lightning, it becomes quite important to understand how we can improve our codebase and ensure that we use best practices. When it comes to building lightning components, they are expected to be pretty much self-contained. It works well when creating standalone components serving specific business function. But, often in enterprise arena we build components having some of common functionality. For e.g. need to validate email or address or a specific business rule validation. A direct approach is to copy and paste the method within helper files of lightning component. But, it is definitely not an advisable approach. So, we have a problem to solve. Lightning provides capability to load external javascript files (static resources) and use it's code. In this article i'll give a quick and simple glimpse of this capability Step 1 - Create a javascript helper file Create a javascript file to contain required shared code...

Note: The main content for this blog post was shared by my friend and colleague Shriram Kabra. There are loads of blogs and articles around managing viewstate in Visualforce pages. As you would know, viewstate is primarily a serialized form of controller state between postbacks. It is very helpful to retain controller's state between client's browser and server. How viewstate works? Every time user opens a visualforce page, Salesforce executes related controller(s). As per controller logic, data is retrieved/ created within memory. This data can also be considered as controller state. If you monitor the lifecycle of Salesforce object (object of controller), it ends as soon as it responds to browser and loses its state. Technically, all subsequent requests for it are fresh page loads. In order for visualforce to retain this state between all postbacks, it needs to store this state somewhere. This is where Viewstate comes handy. While rendering visualforce page,...

While working with Visualforce pages along with javascript remoting functionalities, we often create a lot of callback methods. On top of it, multiple invocations in a chained approach is more chaotic, often hardcoded and leaves code quite unreadable.   Following is an example code while using Javascript remoting within Visualforce page:-   function invoke_remoteService1 (){ console .log ( ' Invoking remote service 1' ); Visualforce.remoting.Manager.invokeAction( '{!$RemoteAction.testWebServiceController.remoteService1}' , remoteService1_ResponseHandler); } function remoteService1_ResponseHandler (response, event){ console .log ( ' Response from remote service 1 = ' + response); if (response ! = null ){ console .log ( ' Invoking remote service 2' ); Visualforce.remoting.Manager.invokeAction( '{!$RemoteAction.testWebServiceController.remoteService2}...

Emails are still a very essential part of our day to day communication. Be it an internal communication within the organization, or across organizations or between customers and organization, emails are one of the key communication mechanism (let's not debate on pros and cons here). Quite obviously, Salesforce provides various options to send emails to internal and external recipients. In this post I'm trying to cover all the essential points (briefly) involved in sending emails from Salesforce. Defining Email Templates First and most important aspect regarding emails is ability to create email templates within Salesforce. This is without doubt one of the most used aspect related to sending emails. Email templates help administrator create pre-defined email templates within Salesforce. This helps in providing business approved and verified templates to system and users. As a result, all outgoing communications are consistent. Also, any correction/ improvement incorporated ...