Salesforce: Some Insights

Frankly, this is a pretty nifty feature I have just observed (never paid attention) and I thought that most of you like me, would have never looked into it. So, hereby sharing it. While implementing Salesforce, one of the key things we showcase to users is the ease with which users can create their own reports with point-and-click features. This is definitely a very important feature for end users as they get the power to create reports in minutes without having to wait for lengthy IT process. Vanilla Salesforce provides lots of report types out of the box as per below screenshot. However, it is quite common that client might not be using certain features of Salesforce and hence those report types are not being used at all. They just clutter the report type list unnecessarily. Salesforce provides a quick way to hide unwanted report types. Just, check the checkbox above "Select Report Types to Hide" and you can hide/ unhide report types. For e.g. we want to hide all

With Dreamforce '15, everyone got ample view of Lightning framework and its benefits or rather "WOW" aspects. I'm equally excited to see a paramount change in Salesforce UX layer which is was much needed. With all the excitement and eagerness to understand and use Lightning we need to also understand the process to transition from Classic UI (current UI) to Lightning Experience, or it can be a rather painful and unsatisfactory experience. Firstly, we need to understand that it's a complete overhaul of User Experience and not mere CSS change. So, the way users interact with application or developers develop the application or architect designs the applications, changes significantly. Secondly, as of now Lightning Experience is not fully enabled for entire Salesforce and is to be done in phases which makes complete sense. You cannot expect users to learn new system overnight and hence a transition is much appreciated. Not to mention, this also gives user

Hi all, as evident from the topic, I'm hereby sharing a small list of configuration options available within Salesforce using which a non-programmer can also develop functionalities within salesforce. The best part of using these features is that you save time, save development/ testing effort, deploy and manage it easily. Standard/ Custom Objects Objects a.k.a. table (for database junkies) a.k.a. entity are used to store data within Salesforce. We can use out of the box objects for e.g. Account, Contact, opportunity, lead etc. (along with their powerful features) or create our own custom objects to store required information for e.g. invoice, purchase orders etc. Custom fields As with any entity, you need to store its attribute, similarly in salesforce an object can have fields. Out of the box objects have standard fields. Additionally, custom fields can be added to standard and custom fields. Following are few special types of fields that can be added to enrich product

How often did each one of us get into a situation where we have to create custom security rules? For e.g. Call center agents should not be able to give credits. Only Supervisors or Finance team can give credits Only Finance and Account Manager can generate invoice. And the most trivial way to achieve it is something like if(profileName == 'Supervisor || profileName == 'Finance'){      // business logic to give credits } else{     //throw error message } Now, one of the best ways to handle this is by using "Custom Permissions". It allows you to leverage Salesforce security infrastructure and loosely bind that to your custom logic. This helps in making your code scalable and robust. You'll learn that below. What are Custom Permissions? Custom Permissions was made GA in Summer '15 (ver 34.0). It is a unique way of creating a custom permission which is required/ to be used by your custom logic. For e.g. in above example, if we create