Salesforce: Some Insights

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