...
This post focuses on HOW to build out Dynamic Forms for your primary objects. This is a HUGE job. Do not undertake this lightly, especially if you have more than two Page Layouts or more then two Record Types. You have to build all of the Record Type functionality you get out of the box with Page Layouts again from SCRATCH! Why is there no Einstein for Dynamic Forms yet that does all of this on convert?
| Info |
|---|
Welcome Redditors and Discord folks. This Page has been linked to from the famous Summer ‘24 Release Notes Abridged Edition. I’m not on Reddit, and SFXD Discord scares me (how do you keep up?!), so feel free to reach out on Twitter (jodiem) or LinkedIn (jminers) for any questions or comments. I’d love to add any more content to this page based on your thoughts too. |
| Note |
|---|
Warning! Someone said the other day “Now that Jodie has given Dynamic Forms them here blessing we can start to use them”. I responded with “With many caveats”. Well I did say previously that I could not use Dynamic Forms until we had Blank Spaces, but my |
...
good golly gosh, they have been implemented in such a half-baked way - why won’t the page layout convert with Blank Spaces intact? And now we get to the actual hard work of having to build functioning Dynamic Forms pages and find that a) we have to completely rebuild all the Record Type and Profile assignment behaviour that we get out of the box with Page Layouts, and b) we STILL have to maintain Page Layouts for many reasons. So If you want to put yourself through all that pain for limited gain, then yes, try Dynamic Forms. |
| Table of Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Firstly, Clone your Lightning Page that you just finished with, in case you need to go back to it, if the user’s can’t deal with things moving around the page.
Having whole sections that move locations, or disappear, or appear at different stages may be very disconcerting to the users.
Try to NOT move the same field to a different location.
Be very careful with which fields hide and show - try to include only fields at the bottom of a section, or in a new section.
Be just as careful for the opposite directions - especially if it’s usual for records to go back a stage.
Eg there is a “new feature” that if a field in the right column disappears, the left column “helpfully” becomes one long column. NO, we DO NOT WANT THAT! Users do not need to wonder why the Amount field is twice as wide sometimes as others, and the Amount field should never be a wide column! So ensure you have a blank space that is made visible with the opposite condition of removing the field from visibility.
Try to label the sections for when they appear, to help the users understand that eg
Payment Information (Closed Won).
Try to only pick one or two reasons that fields show and hide on the same record eg
A Stage Changes
A Date entered
Has related records for X
Has a key lookup field entered
Keep fields that make the section appear eg
If a section is updated via an Integration (eg creation of an Opportunity for a Donation), then it could be one of the fields in the section that is entered that causes the section to be visible,
But that won’t work if the fields in the section must editable at any time.
You may want to add checkboxes or (god forbid) Multi Select Picklists to control which sections of the page are visible.
Start with the low hanging fruit
Sections that don’t need to be there on Closed Won
Go back to the old idea of a Closed Case Page Layout and only show things that are needed on Closed records.
But, users probably want everything, AND the fields that need to be there on Close. So maybe put those other fields in conditional tabs.
Sections that don’t need to be there until a Stage is met.
Ensure they are still there at every later stage, (unless absolutely not necessary).
If you have sequential stages, then create a “helper formula” of IsProposal, that includes the stage of Working and Proposal, or IsNegotiation that contains Working, Proposal and Negotiation.
Or use Probability instead (if it 100% tracks with Stage).
Or create your own probability style field - Stage Number so you can stay Stage < 4 or Stage > 3. This may be useful where there are the same number of Stages between Record Types, but with different Names.
Now, remember you can have a field on the page multiple times. So you might have a field that belongs in a section that is only visible as Stage X, but you could display it in another section if it sometimes gets filled out earlier, and also include it in that Stage section. Especially if you are using Conditional Tabs.
Clean up that ugly System fields section.
This is the FIRST section to move onto Conditional Tabs.
Your users do not ever want to see the Opportunity Name? Sure, move it to another tab.
Name the Tab “Settings” or “Structure” or something useful
ENSURE YOU KEEP Created Date, Last Modified Date, Owner, Record Type.
Removing these breaks “Salesforce” (as in you may as well have any old Database in the cloud)*.
Extra Fancy Ideas
Create a Tab for System Fields, or Control Fields that is only visible by Admins.
Yes, we could not have lived without Salesforce Inspector for all these years, but now we can add ALL the fields directly onto the record.
Salesforce Inspector is still fabulous to find a field or find a value though.
Create a Tab for each Document, or Integration. Conditionally display the Tab only when the user would click the button to send the Integration or build the Document.
Include every field on that page that is in the Document or sent over to Integration.
Often these are fields that are not visible on the page layout.
Include them in the order they are in the document. This is actually a good use of single column fields.
Make them editable still.
Include fields from other records using Related Records or Dynamic Lists
Unfortunately Opportunity Contact Roles are NOT available in Dynamic Lists
The user can then quickly scan down the fields to see what is missing on the document or in the integration, and edit it then and there before clicking the button.
For bonus points find a way to add the button to the Tab (see above).
Bring your Related Lists out onto separate tabs for different Departments
Include field sections for that department only.
HOWEVER note that those fields WILL be shown twice on Edit and New IF they are on the Department Tab and the main Tab, and that may be disconcerting to users.
Idea from Daniel Hoechst, create a tab called Current Stage which only shows the fields required for the current Stage, and then add all the fields on another tab. Now with Conditional visibility, you can build out these tabs separately and hide and show the tab. I used to do this with Related Records Components.
Make sure you remove the stupid Path fields if you do this.
Anther idea from Daniel Hoechst, if you have two Record Types, lay out the fields for each Record Type on different Tabs, and conditionally display the tabs. I think that is a great idea.
Pity we can’t convert multiple Record Type Page Layouts to different Tabs and we have to rebuild them all.
You can still have multiple tabs for a Record Type, and hide them all for the other Record Type.
And Idea from Bill Florio. Have fields visible based on Record ID is null, so fields appear at the top of the page when creating a new record
However, be sure to check this with users, so the fields don’t “disappear” when the record is saved.
The ability to customise Edit pages won the latest silly prioritization round on the Idea Exchange
...