With the release of Dynamic Forms, Salesforce has been moving away from its page layout editor. Dynamic Forms is a huge time-saver for admins and developers because it lets you drag individual fields onto your Lightning page and also manage them in a single place. Yet, today, that capability is only available for custom objects. It's not available in Experience Cloud or mobile either.
What if you need to configure conditional visibility on fields for standard objects? Skuid can help.
Conditionally render a column/field on the Opportunity record based on an Account record value.
While with Dynamic Forms you can only show or hide fields on custom objects, with Skuid you can conditionally render anything: fields, buttons, columns, charts, groups of components, individual components, etc., for both custom and standard objects.
Skuid display logic is really robust and you can get as granular as you’d like—down to a column or even a row action on a table.
To make the magic happen, behind the scenes we use Skuid models, which allow you to set up multiple objects in one UI, in combination with Skuid display logic, which allows one object to affect the display of another one.
For instance, we configured our Opportunities table to only show a record's Stage field if that record's related account has an account type of "Other."
Here’s how we did it:
- In the Skuid Composer, we went into Field properties in Stage (within the Opportunity object)
- We added a render condition based on the Model field value from the myAccount model, looking for a value from the Account Type field equal to “Other.”
You can set display logic off many source types: model properties (i.e., whether the model has unsaved changes or X number or rows), row properties (i.e., whether it’s a new record or already exists), viewport width (i.e., show or hide on mobile), page URL parameter, and much more.
Using the model field value for conditional rendering is powerful because you can show or hide items on a page based on a field from anywhere. Your model could be on a related object or an unrelated object. It could even be connected to a data source outside Salesforce, so it's possible to have your UI react to data from a SQL database or REST API. If you can connect to it with a model, you can use it to dynamically display data in Skuid. And though we only added one render condition, you can add as many as you need.
In the case of our example, when a user changes the Account Type field to Other, the Opportunities table immediately updates to show the Stage field—even before the data is saved. Again, the logic is driving off a field value from a different object.
Before
After
How might you apply this? Here are a couple examples:
- If a user is working an escalated case in Service Cloud, you could display the primary account contact for ease of access.
- To bring more visibility to high-value opportunities, you could configure the Opportunity records to show or hide fields based on the amount of an opportunity.
The flexibility of being able to set your page's UI to react based on any model field value helps you create powerful, dynamic experiences.
Edit multiple records types inline.
Record types can be used for many different things, from defining page layouts in Salesforce to defining processes. Because of this, one highly requested Salesforce feature is the ability to edit multiple record types inline within a single list view. You can’t do this out of the box yet, but that’s where Skuid can help.
We treat record types like any other reference field. That means you can easily pull record types into Skuid forms and tables, giving you more control to support how your users work.
In the webinar, we showed an account list page created using Skuid that displayed all our accounts, across all account record types (i.e., not confined to just one record type at a time).
In this example, we chose a dropdown field to display the record type, but you can choose any other type of field for display. As we edited the account list, depending on the record type we chose, the next dropdown would only display options relevant to that record type, respecting the dependent picklists configured in Salesforce.
Again, Skuid makes this possible because it sits on top of your data model and process automation in Salesforce. And this is one of the benefits of working within the Salesforce ecosystem: we can take advantage of its powerful data modeling capabilities and you can unleash that power with Skuid
On building “vanilla” custom Salesforce apps
It’s the idea that there’s some configuration and some tweaking, but let's stick as close as we can to vanilla. I think it's so important and Salesforce can allow that option as well, because it means that anything you're building, especially if you keep it reasonably vanilla with a little bit of raspberry sauce, it becomes a future-proof and scalable product that you can keep adding to as you iterate with your needs. So, yeah—vanilla is good.
Amanda Beard-Neilson
Salesforce MVP and London’s Calling co-organizer
