Dynamic Forms Known Issues

• If you click View All Dependencies from the Path component, the dependencies that you see come from the record details on the page layout, not from the Dynamic Forms fields on the page.
• The CurrencyISOCode field doesn’t appear as required (with the asterisk) at runtime, although it still behaves as required.
• When you hover over fields in the palette, the data types shown are inaccurate.
• Fields in two-column Field Section components don’t horizontally align correctly. If you want the fields to retain their horizontal alignment inside a field section, select the Align fields horizontally checkbox.
• A record’s printable view is based on the fields from its default page layout, not on the fields on the Dynamic Forms-based page.
• Dynamic Forms field components aren’t supported inside the Macro Builder. When a Dynamic Forms-enabled record page is opened inside of the Macro Builder, the field components don’t appear.
• Universally required fields that are only required for either person account or business account appear in the Universally Required Fields section of the Fields panel regardless of which record type you're building the page for. For example, if you're creating a page for the business account record type, you see both person account and business account required fields in the Universally Required Fields section. If the person account required field isn't present on the page when you save the business account page, you get a warning even though the person account field isn't needed for the business account page.
• The Einstein Account Tier field is missing from the Record Detail component on custom account record pages in the Lightning App Builder and when the account record page renders for users. If you migrate a custom account record page to Dynamic Forms, the Einstein Account Tier field appears in the available fields list and on the record page in Lightning App Builder, but doesn't appear when the page renders for users.
• You can define a Lightning page that supports multiple accounts, like a business account and a person account. You can’t designate different save option values for the business account or person account flow on that Lightning page.
• When you create an object from a related list in the context of a person account using Dynamic Forms, the PersonContactId field isn’t prepopulated in the new record.
• If you edit a field inline and don’t save, then use a quick action to edit and save, your inline edits aren’t saved when your quick action edit is.
• If you move a record to a different status in Kanban view, and the status change triggers a field validation error, it opens the edit window but doesn’t show the error.
• Some field section header labels that are created when migrating a Dynamic Forms page don’t have the same label as the page layout section header. You can update the label in Lightning App Builder.

Packaging Known Issues with Dynamic Forms

• In a non-namespaced org, conflicts can happen if you install a managed package with a Dynamic Forms-enabled Lightning page that's based on an object that exists in the subscriber org and that contains a custom field with the same API name as a custom field on the same object in the subscriber org. The API name conflict between the managed package's custom field and the subscriber org's custom field causes the installed managed Lightning page to reflect the subscriber org's fields instead of the fields from the managed package.

  This issue can also happen with prompt templates installed from a managed package. If the installed prompt template is referenced by a custom field on a Dynamic Forms-enabled Lightning page, and that prompt template itself references a custom field with a namespace that is different from the Lightning page's namespace, package deploy can fail.

  Namespaces are used to differentiate custom object and field names from other orgs' names. For more information about namespaces in orgs, see Understanding Namespaces.

Visibility Rule Known Issues with Dynamic Forms

• Visibility rules based on parent object fields don’t work correctly.
• When you clone a record based on a Dynamic Forms-enabled page that has visibility rules, all the fields referenced in the visibility rules are added to the cloned record, regardless of whether those fields are on the page. The field value used in the rule evaluation and the field’s saved value on the cloned record can vary, depending on the cloning user’s access to the field used in the visibility rule.
  • If the user has read and write access to the field used in the visibility rule, and the field has a value, the source record's original value is used in the rule evaluation and saved to the cloned record.
  • If the user has read and write access to the field used in the visibility rule, and the field has no value, the source record's blank value is used in the rule evaluation, but the cloned record saves with the field’s default value.
  • If the user has only read access to the field used in the visibility rule, the source record's original value is used in the rule evaluation, but the cloned record saves with the field’s default value.
  • If the user doesn’t have read or write access to the field used in the visibility rule, the source value is treated as blank, and the cloned record saves with the field’s default value.
• Values saved in the cloned record of a Dynamic Forms-enabled page depend on the cloning user’s access to the field even when there are no visibility rules assigned. This behavior is different from cloning record detail component values on non Dynamic Forms-enabled pages.

Create from Lookup Known Issues with Dynamic Forms

• Creating a record from a lookup field opens a window with the Dynamic Forms fields only if the object is LWC-enabled. For example, Campaigns, Products, and Tasks still use information from the page layout. See LWC Migration for Record Home Pages for the list of LWC-enabled objects.
• When working with actions, using Dynamic Forms via a Create from Lookup field is supported only for standard actions. Other types of actions, such as default actions and custom quick actions, continue to use information from the page layout.
• On a Dynamic Forms-based page, you get a page error when there are multiple instances of the same lookup field that look up to an object that’s not supported in the UI API. See the User Interface API Developer Guide for the list of supported objects.
• For a non-UI API supported object that has a Forms-enabled object as a related list, if you click New from the related list, the parent lookup field doesn't appear in the New dialog. But you can save the new record.