Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

...

00:00 - Introduction 00:00 - Release Notes 00:28 - Get Started 01:58 - How we work now 02:36 - History of Dynamic Forms 04:20 - What is being delivered 04:38 - Setting the Scene 05:24 - JDDemo 10:50 - Setting up the Lightning Pages 11:59 - Convert the Page Layout 12:58 - Record Types and Page Layouts 13:47 - The Converted Page 14:08 - Mobile Layouts (not covered) 14:43 - Lightning Page Issues 16:30 - The Rules for Classic Page Layouts 17:34 - Compact Layouts and Hovers 19:22 - Building the Lightning Page 20:22 - No Record Previews 21:40 - Conditional Visibility of Sections 22:42 - The Fields Panel 23:51 - Weirdness with placing fields 24:51 - Why do Reports work different to Pages? 25:53 - You can add in bulk, but not delete bulk 27:01 - No Related Records Fields 28:26 - View the Page 29:30 - Comfy vs Compact Layouts 30:00 - Differences between components 30:44 - Layout Display Issues 32:34 - SLDS vs Salesforce 34:50 - Narrow Column Field Sections 37:06 - No Blank Spaces Hack 38:26 - What will be our new Best Practices 38:48 - Section Headings 39:11 - Save takes a little longer 40:03 - Conditional Fields 40:58 - If you build it, will they want it? 41:10 - Set Conditional Visibility on Status 41:45 - Tips for Conditional Visibility 42:32 - Testing Conditional Visibility 43:39 - Conditional Visibility during Edit 43:57 - Required Fields 46:02 - Using the Edit Button 46:53 - Conditional Sections 48:07 - Field Sections in Tabs 48:56 - Multiple of the same field 50:55 - Required Fields on Related Record Comp 52:12 - Will the users cope? 52:35 - Can we remove Standard Page Layouts? 53:40 - Dynamic Actions 58:41 - Detail Page Links 59:32 - Set up Conditional Actions 59:56 - Why no Conditional Tabs? 1:00:12 - Test Conditonal Buttons 1:00:52 - Set 10 Buttons to display 1:02:38 - Cloning 1:07:53 - Bottom Line (NOTE: Don’t follow my idea here - see below re editing!!) 1:10:07 - Layout Best Practices 1:12:26 - What makes a good page 1:13:18 - Next Steps

...

Summer '20 Release

  • Custom Objects Only AND it isn’t supported on record pages that use pinned-region or custom page templates (as per the setup page).

  • Probably only about half the features needed in Custom Objects

  • So it’s about one quarter delivered.

...

Note

Editing Pages with Dynamic Form Fields

Beware! This doesn’t work well. In video 3 of the Be an Innovator quest they showed how easy it was to add a few fields to an existing lightning page. And it was something I said in my video that you might be able to start slowly and keep the existing pages and slowly add dynamic sections. NOPE, it does not work! Please do not do this!
See this extra video https://www.loom.com/share/bcc773a540c341ddb4fb956d3c07396b explaining it.

You do NOT want two SAVE buttons, one you can’t get to!

Then they doubled down and showed a similar thing in Release Readiness Live! https://twitter.com/jodiem/status/1272823818407403520

...

Nice Things

  • Field API Names (but why isn't reports the same?)

  • Icons for field types

  • Bulk Click and drag! (why can't we have this on reports)

  • Add fields to multiple sections

  • Fields conditionally display as you edit

  • Fields in different sections of the page

  • Can't have two fields with one required and one not (but you can on a Related Record Component)

  • Cloning WORKS! (with a hack)

  • Hiding a section doesn't work until you save, which is good, but it doesn't turn back on in full edit mode

  • As you create new fields, you can just refresh the fields panel to see them. This is good. (Why can’t we have this in reports).

Weird Things

Things I’ve found after trying to build one of these for real.

  • The only way to distinguish, on edit mode, that the field is a formula field, is that you can’t change the UI Behaviour field. No visible indication otherwise.

  • Checkbox fields look like they are disabled. AGAIN WHY ARE THEY DIFFERENT CSS THAN STANDARD? WHYYYYYYYYY!

  • Checkboxes are different height than text fields!!!!! Which results in misalignment of fields.

...

  • Wrapped field names misalign fields also. Thinking of fields in columns after 20 years of thinking of fields as LEFT-RIGHT pairs is NOT a good change.

    Image Added
  • Even a User Field misaligns the rest of the fields. The very first field on the page and it looks terrible!

...

And no, comfy layout is no better!

  • WHY does my edit Modal have a Save & New button? WHYYYYYY?

Bottom Line

  • Can the user handle the differences on custom objects to Account / Contacts / Opportunities / Cases?

  • Can you handle the differences in look?

  • You need to think about and deal with the permissions

  • If you can work out your Assignments - still DO NOT do too many Lightning Pages

  • Can you deal with the edit page being different to the layout page?

  • Maybe if you have record types for just different sections, or different stages, then that is probably good to move

  • Managing buttons in two places (they are needed on the page layouts for mobile)

  • Where you had different page layouts for different buttons, may be good to move

  • If you can handle setting up mobile separately

  • What else does Record Types drive for you

  • You are still going to have to maintain a page layout, so is it worth the overhead yet?

  • How are Profiles are going to work in with this - eg having different page layouts for different profiles within the same Lightning page? What is the future of Profiles WRT Dynamic Forms - since Profiles are going away and being replaced with Permission Set Groups?

  • Need to know about performance implications - eg if I have to duplicate fields to have a slightly different layout for different profiles or perm sets rather than having different lightning Pages (I never want to do more than one Lightning Page unless absolutely necessary).

  • How is this going to work in with the setup functionality - the Perms team could NOT get the setup changed to incorporate Permission Sets into the Field creation screen, so how will this be incorporated into the new field creation and field editing screen.

...

  • Work in standard Objects

  • look EXACTLY the same as the standard Salesforce CSS

    • Alignment

    • Field heights

    • Field widths

  • CSS consistent with lightning

  • Look EXACTLY the same as the fields in the Related Record Components (logo on heading not necessary)

  • Headings to look exactly the same

  • Must have blank space component

  • Must be able to collapse sections

Tips to Set Up

These are my tips as I’m going through setting up a layout for real now.

  • Create as many Formula fields for as many varieties of visibility as you need.

    • Eg for a field that is only displayed after the record is Active, do you want to still have it displayed after the record is expired. So you need a formula for IsActiveExpired where the Status value is Active OR Expired.

      • The selecting of fields in the field visibility is SOOOO HORRIBLE you never want to have more than one selection.

  • 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.

  • Create a Blank Space field - a good option that someone commented on my YouTube video is ALT+0183 for the label, and ““ for the formula. It is as subtle as possible. Another one might be “--------------->” for the label to highlight fields that are only in the right column or “____________________________” to add in above a formula that is a sum of a few numbers above.

  • There will be times where you need to have a field displayed in some circumstances (eg IsActive, but a blank space displayed in the opposite case (eg IsActive = false) so that fields don’t jump around on the page. So the edit page then looks unwieldy and you have to keep in your mind how it’s going to look.

    • Or sometimes you just have to move fields to the top of the section, or add new sections in.

    • Similar if you want to have a field conditionally required, so you add two fields to the section so they appear in the same place but either required or not required.

  • Save Often!

  • It is REALLY HARD to select a section to drag it, so only use the Move Component handle.

  • If you are replacing Related Record Components, drag them into place to where the fields will be going so you can set the fields up the same

  • When the page gets so long, use the + buttons for new section placement. You won’t be able to drag.

  • Have a Control Section with different fields that turn sections off and on. Then repeat that control field in the section it controls. Name the control fields Show X eg Show Extra Charges.

    • It may be best to have these sections in Accordions so the page doesn’t get super long.

  • Have a section that is only visible to Admins that shows all the fields that controls the sections of the page. If you want, even go to the extent of having extra sections on the page near the fields that are going to be controlled, or even have a control field named Xray View that can turn these fields on.

  • You will STILL need Related Record Components, to display fields from other records. Keep them away from these layouts. Eg keep them in the narrow column. Or if they HAVE to be in-line then it’s best that they are read-only due to the duelling edit buttons issue.

...

Yes, this is for real, this is the abomination you can create, with two edit buttons on the screen at the same time.

  • IT IS REALLY HARD TO MOVE SECTIONS AROUND A LONG PAGE! Almost WORSE than Process Builder!

  • You may have to re-arrange fields based on the length of the FIELD NAME! This is ridiculous and bizarre!

Wishlist

  • Control fields only - that don’t take your field limits and don’t need to be set up like a field - maybe that’s asking too much.

  • Collapse sections in the edit layouts, without having to do accordions, or conditional accordions.

  • A quicker way to reposition sections.