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”
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!”
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”
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”
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):
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.
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.
Since Lightning Experience was released, the concept of Classic App and Lightning Apps came up.
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.
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>
Last week I had the pleasure of presenting at French Touch Dreamin event. I gave a talk about Security, in which I explained some of the main things a developer has to take into account in order that our Salesforce applications are secure. I explained how to take care of CRUD, FLS and sharing, and also of known important vulnerabilities as XSS (cross site scripting), CSRF (cross site request forgery), open redirect or SOQL injection.
