Dynamic Forms for Flow – Overview
The Dynamic Forms for Flow feature makes it easier to create flow screens by allowing you to directly insert fields onto the screen. The Traditional Flow approach, that you’re familiar with, is more flexible but more complicated: you first add your component of choice to the screen and then associate some data with it.
The Traditional approach makes it easy to effectively combine data and use it downstream and will continue to be a fundamental part of flow creation. But we wanted to provide a way to do what you can do in a lot of other parts of Salesforce: specify a particular Object type (i.e. “Account”) or Record and then work directly with a palette of convenient fields.
This is paradigmatically similar to what our colleagues at App Builder did when they made it possible to create layouts from a palette of fields, directly from within App Builder, and not have to use the traditional Page Layout approach. Because of that similarity, we opted to call the Flow feature Dynamic Forms for Flow.
In Screen Builder, a new Fields tab provides this display:
As of Summer ’22, you need to provide Screen Builder with a record variable. This essentially tells Screen Builder whether you’re creating a new record (in which case the fields will be blank or contain default values) or whether you’re working from an existing record (in which case it will populate the field values with the values of the record variable that you provide.
Here’s an example:
I have an existing Knowledge record that has these field values:
I use this Get Records to load the record and an Assignment element to assign it to a record variable called curKnowledge:
Then the manual variable is provided to Screen Builder, which enables it to establish the retrieved Knowledge record as the starting point for display and edit:
When this flow is run, the screen populates with the existing value. Here you can see a traditional Record Detail side-by-side with a “KnowledgeFlow”:
Why might you choose to use a flow with dynamic forms instead of a traditional Record Detail? That’s a deep topic for another day, but I’ll point out one small but often-requested benefit. If you look carefully at the two approaches in the image above, what’s different? Knowledge experts will know that URL Name is actually a required field, and Salesforce veteran will know that you have never been able remove required fields from traditional page layouts. With our flow screen, however, it’s an easy matter to leave it off the view, creating a simpler, more focused experience for Knowledge users.
Note 1: Extra Credit Question
Why did I choose to use an Assignment element rather than use the ‘Choose fields and assign variables’ option in Get Records?
Answer: Although adding the Assignment element is a little more complex, it frees me from having to manually define all the fields in the Get Records configuration. If I later add or modify fields on the Knowledge object, they will automatically show up in Screen Builder’s Fields tab because Flow knows the Screen Builder wants all of the fields. The older ‘Choose fields and assign variables’ will not go beyond the static fields that it has specifically been told to choose, so you’d have to go back into the Get Records and update it each time you changed the Knowledge object
Note 2: Record Variable doesn’t get reloaded into the picklist even though it’s assigned
This is a bug, because once you save a flow with a record variable selected in a screen, the metadata records that relationship. Unless you put a different variable in the Record Variable picklist, those relationships will persist.
Creating and Updating Records In Flow with Dynamic Forms
To create a record using Dynamic forms:
- Add a Record Variable of the type you want to create. For example, an Account variable called newAccount.
- Add a Screen element, select the Fields tab, and select your record variable in the Record Variable combo box
- Drag fields onto the screen. If you need to gather data for a field type that’s not yet selected, you can switch to the Components tab and mix and match components and fields.
- After the Screen element, any data entered into fields will be automatically present in your record variable. If you also gathered data using components, you’ll need to map that data into your record variable. You can do this either by 1) Using an Assignment element or 2) using Manual Variable Mapping in the Advanced section of the property editors for the components
- At this point, your record variable has all of the information entered by the user, and you can pass it into a Create Records element.
Updating is almost identical. The only differences are that you load an existing record into your record variable in Step 1, and use an Update Records element in step 5.
What Works And What’s on the Roadmap
Conditional Field Visibility does not yet work if a Field is used as a parent component.
Picklists work as of Spring 22 but they don’t respect record types yet.
You can’t use automatic output handling yet. When this is added, the entire Record Variable step can be omitted.
Local Overrides will allow a Flow to override some of the field’s underlying values. One notable example of this is being able to use a new label instead of an old label that’s obsolete but can’t easily be changed.
More field support: Name, Address, and Lookup fields are currently next in line.