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!
Creating pre-populated records with lightning:recordEditForm
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:
Continue reading “Creating pre-populated records with lightning:recordEditForm”
10 things to know about Platform Developer I and Developer II exams!
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.
Continue reading “10 things to know about Platform Developer I and Developer II exams!”
Controlling record level security with Sharing
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.
Continue reading “Controlling record level security with Sharing”
Bound and unbound expressions in Lightning Components
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.
Continue reading “Bound and unbound expressions in Lightning Components”
Analyzing Big Objects data
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?
Big Object field types workarounds
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):
- Text
- Number
- Datetime
- 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.
10 thoughts about Big Objects
Two weeks ago I had the pleasure to give a talk about how to use Big Objects & Async SOQL to build your Big Data solution in Salesforce, with my super colleague Agustina García, at Dreamforce. You can check the video of the talk here.
In this post I want to highlight the 10 key things to remember about Big Objects, one of the features we talked about in the presentation.
Classic Apps vs Lightning Apps
Since Lightning Experience was released, the concept of Classic App and Lightning Apps came up.
- Classic App: an application that has been built in the Classic UI. You can make it visible in Lightning Experience, but that does not convert it into a Lightning App.
- Lightning App: an application that has been built in the Lightning Experience UI.
In this post I want to talk about the benefits that Lightning Apps introduce, with an extra bonus of things to take into account if you are an ISV who builds managed packages.
Property ‘picklist’ not valid in version …
Have you recently faced this error while trying to deploy using API 39.0 or later? This is happening to you because <picklist> tag was deprecated in API 39.0.
Here you have how to fix it:
Object definition before API 39.0:
<fields> <fullName>Status__c</fullName> <externalId>false</externalId> <label>Status</label> <picklist> <picklistValues> <fullName>No Started</fullName> <default>false</default> </picklistValues> <picklistValues> <fullName>In Progress</fullName> <default>false</default> </picklistValues> <picklistValues> <fullName>Completed</fullName> <default>false</default> </picklistValues> <restrictedPicklist>true</restrictedPicklist> <sorted>false</sorted> </picklist> <required>false</required> <trackTrending>false</trackTrending> <type>Picklist</type> </fields>
Object definition after API 39.0:
<fields> <fullName>Status__c</fullName> <externalId>false</externalId> <label>Status</label> <required>false</required> <trackTrending>false</trackTrending> <type>Picklist</type> <valueSet> <restricted>true</restricted> <valueSetDefinition> <sorted>false</sorted> <value> <fullName>No Started</fullName> <default>false</default> <label>No Started</label> </value> <value> <fullName>In Progress</fullName> <default>false</default> <label>In Progress</label> </value> <value> <fullName>Completed</fullName> <default>false</default> <label>Completed</label> </value> </valueSetDefinition> </valueSet> </fields>
