...
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?
| Table of Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
My Scenario
Opportunity
Two Record Types
A Page with
Details section
Highlights Panel
Dynamic Related List on main page
Activity and Chatter
4 Tabs
3 Related Record Components to display different sections of the current record
Rich Text Component
About 80 visible fields, so not too big.
Wishlist
Much more structured page layout.
Conditional sections for Record Types and Stages.
Conditional Tabs for Document Generation.
Conditionally display key details at the top, depending on the Stage.
Part One - First Tentative Steps
Setup
Summer '24 org
Do this in Sandbox
Install Clear Cache extension
Set it to remove Indexed DB, Everything, and reload the page (no other settings).
This will stop you being “gaslightninged”.
Every time you save the page, use the Clear Cache extension, and you won’t ever have to worry about if the field will appear on the page, it will!
(yes, you can turn of the Lightning Cache in Sandbox, but using the Clear Cache extension is just so quick and easy and works everywhere).
Turn on Compact Layout
Turn on Dynamic Forms for Mobile
EVEN if you will never use Dynamic Forms on Mobile, just turn it on!
It gives you conditional tabs.The conditional tabs being tied to Salesforce Mobile has apparently been fixed now.
Turn on Dynamic Actions for Mobile
App
Clone your main App
Mainly if this is the biggest object you use. If it’s just a tiny object, don’t worry about this new App step.
Deploying the new app and everything in it will be easier.
This will allow your users to slowly transition, and move back to the old app if needed at any time.
Create Buttons or URL formula fields on the page linking between the old and new App, to encourage users to use the new pages, but go back to the old pages if they get stuck.
The url includes the developer name from the App Manager page
Code Block https://[yourorg].lightning.force.com/lightning/app/c__[YourApp]/r/[Object]/[recordId]/view
It will also allow you to build into the new app, some of the new features you haven’t used yet. I know there are at least 3 you haven’t touched yet!
Dynamic Actions
Dynamic Related Lists (despite their issues)
If you have users that use Console Apps, then ensure that is an App you create new for using Dynamic Forms.
Ensure your App is available for Desktop and Mobile.
Permissions
This is ALSO a great time to start moving from Profiles to Permission Sets. At the very least:
Create a few main Permission Sets for Admin, and your key user groups, give them Edit Access to that Object.
Turn on “Field-Level Security for Permission Sets during Field Creation” in “User Management Settings”
Remember to Assign those new Permission Sets to the Users or go to the next Step and create a PSG for each main group. You can have a PSG and still have fields controlled by Profiles. Just any new Fields you create will be starting you on this path to Permission Sets.
ESPECIALLY create PSGs if you are using Custom Permissions also. So much easier to do up front.
Lightning Page and Page Layout
Clone your Lightning Page, and make it available only to the new App
This is also a good opportunity to consolidate the number of Lightning pages you have down to as few as possible.
Have a good reason to have more than one*.
Check your Page Layout you are going to convert from
Remove any buttons that you won’t use
Remove any blank sections
Remove any related lists not in use (eg Notes & Attachments, Notes)
You are NOT using Notes are you?*
Convert your Page Layout
DO NOT use the Accordions option!*
View the Page
Now save and view your page, and start to get a feel for how different the page looks from standard.
Have the exact same record open in another app on another monitor, to compare.
Note the god-awful way the fields bunch up vertically in each column, and don’t align across the columns.
And notice all your blanks spaces have gone.
Edit the page:
in full page mode (clicking the edit icons),
in modal mode (clicking the edit button).
Test Creating New:
Are all the fields there needed
Create New of each Record Type
NOTE that there is no difference anymore, you now have to rebuild that whole functionality yourself
Test Creating new via Global Actions
Are they still what you need to create the basic record?
Test Cloning:
Remember Cloning STILL only works based on your old Page Layouts, so you may have to adjust them if you want to Clone.
And this may be annoying for users who want to go back to the “old” page layouts app.
I would suggest using a Flow to Clone and use the new Transform element, it works really well.
Remove the standard Clone button if you don’t have the right fields to Clone.
First Fixes
Immediately make the first round of fixes.
Set all Sections to have Horizontal Alignment.
Add back in your Blank Spaces. ALL OF THEM.
Save and view the page again. Sigh with relief.
Create “Helper Fields” for conditional visibility:
Eg one for each Record Type. Given Record Types of Sales and Service, create IsSales and IsService. These will help you quickly set up conditional visibility.
If you need to have a condition where a field is conditionally displayed if a picklist field is blank then you need to create a formula. There is no way to do this with visibility rules.
The selecting of fields in the field visibility is SOOOO HORRIBLE you never want to have more than one selection.
NOTE: if you are nearing your 500 or 800 field limit, then these helper fields may not be helpful.*
Create Custom Permissions to help you hide buttons or sections from groups of people rather than using Profiles. Create Helper fields for Sales and Service users as IsSalesUser, IsServiceUser
Of course you don’t have to do this for obvious buttons like Delete, but there are so many other buttons that are just not useful for other users to see.
AND you lose Custom Links so you have to change all those to Buttons so you will want to make those Dynamic (see below).
Now, convert every Related Record Component that is for the “same object” into a Field Section.
You have to do this manually by dragging each field onto the page.
Remember to align fields horizontally and add blank spaces where you need to.
Add the same conditional visibility as was on the Related Record Component.
Remove the Related Record Component.
TIP: build your section at the top left hand side of the page to make it easy to drag the fields just a short way.
TIP: Filter the fields so you don’t have to scroll - eg do all Amount fields at once.
TIP: If you have two similar sections, build them at the same time, or Copy and Paste one section to another.
Now, rearrange your page - your narrow column is now useless, for anything except maybe Related record field details that are not editable.
Even attempt different page arrangements.
Header and 3 regions is a bust
Header and 2 equal regions may be useful, but busy.
Don’t go too crazy, you don’t want this object to be way different looking than every other object, or do you? It is you that is going to have to go through all the change management and training and “who moved my cheese” with all your users.
The other page layouts (Pinned Header etc), now work with Dynamic Forms apparently, but they are only available if you create a brand new Lightning Page from scratch.
But they are still a bust due to narrow columns being useless for fields.
Get used to Cutting and Pasting rather than dragging sections. Dragging sections is a drag!*
Re-Create the Record Type functionality
Now, ensure that each of the main sections that are visible for each Page Layout for each Record Type and / or Profile have been created and conditional visibility applied.
Buttons and Quick Links
If you have not already set up Dynamic Actions now is the time to do that, ensuring the buttons required for each Record Type and or Profile are visible.
TIP: Use Custom Permissions and “Helper Fields” as noted above to help with hiding buttons.
If you have any Custom Links, I’m sorry. This is one of the highly annoying things.
Either, recreate them all as Buttons - I say recreate them because you still may want the Custom Links on the App that still has the old page layout for a time.
Unfortunately Reports don’t open in a new tab, at all, like Custom Links do. It is highly highly highly annoying.
And the Button overflow bar is going to get far too long.
Or, create them in a Flow - is that even possible? I don’t know.
Or, create them as a field as a Hyperlink Formula.
Or, create them as Report Charts - which unfortunately requires re-creating ALL the reports as well as creating the charts.
Or, create a Custom LWC that shows them - is that even possible - please, someone make that!
Or, wait another release or three. They say it is in the roadmap.
On the plus side, since you have to do soooo much work you are really going to consolidate and find out which Custom Links are in use.
Salesforce Indicators!
Install and set up Salesforce Indicators!
Yes, now is the time to do it!
It’s something fresh to go with the fresh look of the page, but it won’t be seen as part of the “Dynamic” part of Dynamic Forms.
Test!
Now test everything again:
Clone
New
Edit
Console view
Mobile! (NOTE: I will NOT be focusing on Mobile on this run-through).
STOP!
🛑 NOW STOP! 🛑
Do not try anything fancy.
No moving fields to other tabs.
No hiding sections that are only visible for certain stages.
No conditional tabs.
Give this to the users for at least 2 weeks, if not a month.
It’s up to you if you give them the option to go back to the old App / layout at this stage or only after you start messing with them more.
Let them get used to this bit of cheese being moved, before you unleash anything more.
Again, I’m only talking about your main objects here, be a bit more daring with trivial objects.
Use this time to refine all the other improvements (see below), and work on the next steps in your Sandbox.
You will also get used to the double maintenance you now have to do by having Dynamic Forms, and you will get used to the “gaslightning” that occurs every time you go to make a change.
Read this Blog Post
Michael Kolodner has recently written an excellent blog post on how to design your pages for Dynamic Forms. https://www.freelikeapuppy.tech/post/design-for-user-success-field-placement. For old Page Layouts I swore by this post https://www.shellblack.com/administration/usability-fields-and-page-layouts/, so it is time to update my goto post for sharing with others on how to layout their pages, by now sharing Michael’s post.
Part Two - Now for the Fancy Stuff
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 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.
...
| 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 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
My Scenario
Opportunity
Two Record Types
A Page with
Details section
Highlights Panel
Dynamic Related List on main page
Activity and Chatter
4 Tabs
3 Related Record Components to display different sections of the current record
Rich Text Component
About 80 visible fields, so not too big.
Wishlist
Much more structured page layout.
Conditional sections for Record Types and Stages.
Conditional Tabs for Document Generation.
Conditionally display key details at the top, depending on the Stage.
Part One - First Tentative Steps
Setup
Summer '24 org
Do this in Sandbox
Install Clear Cache extension
Set it to remove Indexed DB, Everything, and reload the page (no other settings).
This will stop you being “gaslightninged”.
Every time you save the page, use the Clear Cache extension, and you won’t ever have to worry about if the field will appear on the page, it will!
(yes, you can turn of the Lightning Cache in Sandbox, but using the Clear Cache extension is just so quick and easy and works everywhere).
Turn on Compact Layout
Turn on Dynamic Forms for Mobile
EVEN if you will never use Dynamic Forms on Mobile, just turn it on!
It gives you conditional tabs.The conditional tabs being tied to Salesforce Mobile has apparently been fixed now.
Turn on Dynamic Actions for Mobile
App
Clone your main App
Mainly if this is the biggest object you use. If it’s just a tiny object, don’t worry about this new App step.
Deploying the new app and everything in it will be easier.
This will allow your users to slowly transition, and move back to the old app if needed at any time.
Create Buttons or URL formula fields on the page linking between the old and new App, to encourage users to use the new pages, but go back to the old pages if they get stuck.
The url includes the developer name from the App Manager page
Code Block https://[yourorg].lightning.force.com/lightning/app/c__[YourApp]/r/[Object]/[recordId]/view
It will also allow you to build into the new app, some of the new features you haven’t used yet. I know there are at least 3 you haven’t touched yet!
Dynamic Actions
Dynamic Related Lists (despite their issues)
If you have users that use Console Apps, then ensure that is an App you create new for using Dynamic Forms.
Ensure your App is available for Desktop and Mobile.
Permissions
This is ALSO a great time to start moving from Profiles to Permission Sets. At the very least:
Create a few main Permission Sets for Admin, and your key user groups, give them Edit Access to that Object.
Turn on “Field-Level Security for Permission Sets during Field Creation” in “User Management Settings”
Remember to Assign those new Permission Sets to the Users or go to the next Step and create a PSG for each main group. You can have a PSG and still have fields controlled by Profiles. Just any new Fields you create will be starting you on this path to Permission Sets.
ESPECIALLY create PSGs if you are using Custom Permissions also. So much easier to do up front.
Lightning Page and Page Layout
Clone your Lightning Page, and make it available only to the new App
This is also a good opportunity to consolidate the number of Lightning pages you have down to as few as possible.
Have a good reason to have more than one*.
Check your Page Layout you are going to convert from
Remove any buttons that you won’t use
Remove any blank sections
Remove any related lists not in use (eg Notes & Attachments, Notes)
You are NOT using Notes are you?*
Convert your Page Layout
DO NOT use the Accordions option!*
View the Page
Now save and view your page, and start to get a feel for how different the page looks from standard.
Have the exact same record open in another app on another monitor, to compare.
Note the god-awful way the fields bunch up vertically in each column, and don’t align across the columns.
And notice all your blanks spaces have gone.
Edit the page:
in full page mode (clicking the edit icons),
in modal mode (clicking the edit button).
Test Creating New:
Are all the fields there needed
Create New of each Record Type
NOTE that there is no difference anymore, you now have to rebuild that whole functionality yourself
Test Creating new via Global Actions
Are they still what you need to create the basic record?
Test Cloning:
Remember Cloning STILL only works based on your old Page Layouts, so you may have to adjust them if you want to Clone.
And this may be annoying for users who want to go back to the “old” page layouts app.
I would suggest using a Flow to Clone and use the new Transform element, it works really well.
Remove the standard Clone button if you don’t have the right fields to Clone.
First Fixes
Immediately make the first round of fixes.
Set all Sections to have Horizontal Alignment.
Add back in your Blank Spaces. ALL OF THEM.
Save and view the page again. Sigh with relief.
Create “Helper Fields” for conditional visibility:
Eg one for each Record Type. Given Record Types of Sales and Service, create IsSales and IsService. These will help you quickly set up conditional visibility.
If you need to have a condition where a field is conditionally displayed if a picklist field is blank then you need to create a formula. There is no way to do this with visibility rules.
The selecting of fields in the field visibility is SOOOO HORRIBLE you never want to have more than one selection.
NOTE: if you are nearing your 500 or 800 field limit, then these helper fields may not be helpful.*
Create Custom Permissions to help you hide buttons or sections from groups of people rather than using Profiles. Create Helper fields for Sales and Service users as IsSalesUser, IsServiceUser
Of course you don’t have to do this for obvious buttons like Delete, but there are so many other buttons that are just not useful for other users to see.
AND you lose Custom Links so you have to change all those to Buttons so you will want to make those Dynamic (see below).
Now, convert every Related Record Component that is for the “same object” into a Field Section.
You have to do this manually by dragging each field onto the page.
Remember to align fields horizontally and add blank spaces where you need to.
Add the same conditional visibility as was on the Related Record Component.
Remove the Related Record Component.
TIP: build your section at the top left hand side of the page to make it easy to drag the fields just a short way.
TIP: Filter the fields so you don’t have to scroll - eg do all Amount fields at once.
TIP: If you have two similar sections, build them at the same time, or Copy and Paste one section to another.
Now, rearrange your page - your narrow column is now useless, for anything except maybe Related record field details that are not editable.
Even attempt different page arrangements.
Header and 3 regions is a bust
Header and 2 equal regions may be useful, but busy.
Don’t go too crazy, you don’t want this object to be way different looking than every other object, or do you? It is you that is going to have to go through all the change management and training and “who moved my cheese” with all your users.
The other page layouts (Pinned Header etc), now work with Dynamic Forms apparently, but they are only available if you create a brand new Lightning Page from scratch.
But they are still a bust due to narrow columns being useless for fields.
Get used to Cutting and Pasting rather than dragging sections. Dragging sections is a drag!*
Re-Create the Record Type functionality
Now, ensure that each of the main sections that are visible for each Page Layout for each Record Type and / or Profile have been created and conditional visibility applied.
Buttons and Quick Links
If you have not already set up Dynamic Actions now is the time to do that, ensuring the buttons required for each Record Type and or Profile are visible.
TIP: Use Custom Permissions and “Helper Fields” as noted above to help with hiding buttons.
If you have any Custom Links, I’m sorry. This is one of the highly annoying things.
Either, recreate them all as Buttons - I say recreate them because you still may want the Custom Links on the App that still has the old page layout for a time.
Unfortunately Reports don’t open in a new tab, at all, like Custom Links do. It is highly highly highly annoying.
And the Button overflow bar is going to get far too long.
Or, create them in a Flow - is that even possible? I don’t know.
Or, create them as a field as a Hyperlink Formula.
Or, create them as Report Charts - which unfortunately requires re-creating ALL the reports as well as creating the charts.
Or, create a Custom LWC that shows them - is that even possible - please, someone make that!
Or, wait another release or three. They say it is in the roadmap.
On the plus side, since you have to do soooo much work you are really going to consolidate and find out which Custom Links are in use.
Salesforce Indicators!
Install and set up Salesforce Indicators!
Yes, now is the time to do it!
It’s something fresh to go with the fresh look of the page, but it won’t be seen as part of the “Dynamic” part of Dynamic Forms.
Test!
Now test everything again:
Clone
New
Edit
Console view
Mobile! (NOTE: I will NOT be focusing on Mobile on this run-through).
STOP!
🛑 NOW STOP! 🛑
Do not try anything fancy.
No moving fields to other tabs.
No hiding sections that are only visible for certain stages.
No conditional tabs.
Give this to the users for at least 2 weeks, if not a month.
It’s up to you if you give them the option to go back to the old App / layout at this stage or only after you start messing with them more.
Let them get used to this bit of cheese being moved, before you unleash anything more.
Again, I’m only talking about your main objects here, be a bit more daring with trivial objects.
Use this time to refine all the other improvements (see below), and work on the next steps in your Sandbox.
You will also get used to the double maintenance you now have to do by having Dynamic Forms, and you will get used to the “gaslightning” that occurs every time you go to make a change.
Read this Blog Post
Michael Kolodner has recently written an excellent blog post on how to design your pages for Dynamic Forms. https://www.freelikeapuppy.tech/post/design-for-user-success-field-placement. For old Page Layouts I swore by this post https://www.shellblack.com/administration/usability-fields-and-page-layouts/, so it is time to update my goto post for sharing with others on how to layout their pages, by now sharing Michael’s post.
Part Two - Now for the Fancy Stuff
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
Things to Consider
In Training and whether it is the right time to unleash this to users.
Don’t do this too quickly, yes, I am sure the users have been hassling you for this since 2018, or 2020, but if it’s not rolled out well, they will not want to do it for any other objects and then they may lose some excellent benefits. This is especially if you don’t get the Record Type behaviour 100% matching what they have now.
For teams that rely on Mobile devices heavily, I would be even extra cautious, and test everything super well before making Dynamic Forms live.
How will the record creation and record change process change for users. The weird page layout with the fields on tabs below the System Information may be difficult to deal with. People will be saying they have to scroll too far to quickly create or edit a record.
There are ways to address this but it is such an administrative burden.
Follow the progress of this idea that is part of the May 2024 Prioritisation round.
What will it look like when you jump from a record with Dynamic Forms to a record without Dyanamic Forms? Will it be too disconcerting for the users?
Read Michael’s blog post around consistency of page layouts. I think if the fields are consistently laid out, it could be OK.
What will your maintenance overhead be? Is it worth it?
No matter what you think, you will have to maintain both Page Layouts and Lightning Pages. There will be something you need that is controlled by Page Layouts. And you do want your Page Layouts to be at least a little consistent with the Lightning Page, and not just dumping everything in the one section.
What will be the effect of being “gaslightninged” every single day when you go to the Page Layout and change a field position, or add a button, then go to the Lightning Page and refresh, and take 10 refreshes, and 5 minutes to realise that Oh, this is Dynamic Forms!?
Other Things to Fix whilst you’re at it
...
Whilst we can now see which fields are required, we still can’t see which fields are on the page already, or where they are.
Look of the Page
To debug a Flow
It still LOOKS different to every other page.
Why can’t they just get the CSS of the height of the section headings and the font of the section headings consistent with standard pages, let alone the height of the fields, and the edit icons.
Checkboxes are still taller than other fields.
Why on earth do I have to set every single section to have the basic ability to align fields. When is anyone EVER going to NOT have them aligned!
Page Layouts are still required
the fields, and the edit icons.
Checkboxes are still taller than other fields.
Why on earth do I have to set every single section to have the basic ability to align fields. When is anyone EVER going to NOT have them aligned!
Page Layouts are still required
To debug a Flow
To in-line edit a field on a List View
If you need different fields to be editable based on different Record Types you still need different page layouts for each Record Type.
And the field has to be editable on the page layout - not Read Only. Thanks Daniel Hoechst for the clarification.
Anywhere where code is required to look through the fields on a page layout
Formstack
...
Remove all buttons from the Page Layout other than those needed for Activities.
That will give you a hint when you go to add a new button to the Page Layout
Maybe Create a Formula field named “AAA DYNAMIC FORMS ENABLED” and add it to the top of your Page Layout to prevent you from adding fields to the Page Layout when you have forgotten.
Use ctrl+f to find the fields on the Lightning page.
...