Lightning Pages are a concept introduced by Salesforce to allow creating and customizing pages in Salesforce with simple drag & drop, for Lightning Experience and Salesforce1. In this post I want to explain how these pages behave in a managed package environment.
Last week I discovered something about Lightning Components I didn’t know about: aura:action. This is an attribute type that you can use to pass actions to a child component, in addition to the other supported attribute types, and it can be specially helpful if you want to decide at component instantiation which actions should the child component perform.
When working with Lightning Components framework it is very important to understand how the different components are rendered by the framework, which possibilities do we have to interact with the component lifecycle and how will the framework react to certain events as for example a change of an attribute. Want to know more? Continue reading!
A typical use case when creating records is to populate some fields in advance, and then let the user fill in the rest of required fields. Let’s say that we want to create account records, having a pre-populated description, like this:
It has been a while I don’t write a post and this is because I was studying for Dev I and II exams. The good news is that I passed both! In this post I am going to try to give some advice about each of the certifications.
As next week I will give a talk about security at London’s Calling, I would like to create a blog post series regarding to Salesforce security for developers. I already talked about CRUD and FLS in a previous post so I thought it was a good idea to continue with sharing.
Sharing is the common way of referring to record level security in the platform, this is, the settings that control if a user X will have read (&report) / write / transfer / delete / share permissions for a specific record Y.
Today I want to take a look at the data binding possibilities that exist for Lightning Components attributes. We will see how attributes can be referenced using bound or unbound expressions, and which implications will these bindings have in our application.
Following with the blogs I have recently written about Big Objects, as this one or this one, I want to finish this blog series for now talking about one use case that I am sure you have thought about when reading the previous posts.
Imagine that you have some Big Objects in your organization. You have stored some data there, and now, you want to report on them. As you probably know if you read this post, search, reports and dashboards are not available for Big Objects. How can we accomplish this?
If you have taken a look at Big Objects, you will have noticed that we can only create fields of the following types (information valid for Winter 18 release):
- Lookup to Standard or Custom objects
Big Objects can be used for multiple purposes, but typically, archiving old records is one of the use cases. What can you do if you need to archive a custom object which has field types that are not supported, as for example picklist or master-detail? What if you want to create lookups to Big Objects? Read this post and you will find a solution.