--- schema_version: "1" id: 40d02fff1c1a191da8ef3c1e2e149cf1ed0acca07e6f9ff561dc0e11c758a957 title: Dynamic Forms Known Issues collection: admin version: current locale: en-us portal_url: https://docs.salesforce.com/admin/current/en-us/platform/264-0-0/dynamic_forms_known_issues.md canonical_url: https://help.salesforce.com/s/articleView?id=platform.dynamic_forms_known_issues.htm&release=264.0.0&type=5 source_site: help.salesforce.com content_type: documentation content_hash: 91fa6ff4cd05c5f2735d9c1b8e5eb332f9552973ef7980bcb2186e89c8fd5ab1 description: Keep these known issues in mind when working with Dynamic Forms. products: - Salesforce Platform - Security release: "264" --- # Dynamic Forms Known Issues Keep these known issues in mind when working with Dynamic Forms. ### Required Editions
Lightning App Builder available in: Salesforce Classic (not available in all orgs) and Lightning Experience
Lightning pages and Dynamic Forms available in: Lightning Experience and the Salesforce mobile app

Available in: Group Essentials, Professional, Enterprise, Performance, Unlimited, and Developer Editions

- 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 run time, 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 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](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_plan_namespaces.htm). ## 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](https://help.salesforce.com/s/articleView?id=xcloud.basics_clone_records.htm&type=5&language=en_US) 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, Products and Tasks still use information from the page layout. See [LWC Migration for Record Home Pages](https://developer.salesforce.com/docs/platform/lwc/guide/migrate-lwc.html) 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](https://developer.salesforce.com/docs/atlas.en-us.uiapi.meta/uiapi/ui_api_get_started_supported_objects.htm) 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. #### See Also - [Dynamic Forms Tips and Considerations](https://help.salesforce.com/s/articleView?id=platform.dynamic_forms_considerations.htm&release=264.0.0&type=5 "Keep these tips and considerations in mind when working with Dynamic Forms.") - [Dynamic Forms Limitations](https://help.salesforce.com/s/articleView?id=platform.dynamic_forms_limitations.htm&release=264.0.0&type=5 "Keep these general, migration, and packaging limitations in mind when working with Dynamic Forms.") - [Break Up Your Record Details with Dynamic Forms](https://help.salesforce.com/s/articleView?id=platform.dynamic_forms_overview.htm&release=264.0.0&type=5 "The more fields that there are on your page layout, the more that the Record Detail component becomes a monolithic block of fields that you can’t customize. With Dynamic Forms, you can migrate the fields and sections from your page layout to individual components in Lightning App Builder. Then you can configure them the same way as the other components on the page - spreading them out across multiple columns and tabs, and dynamically showing and hiding them based on record data, user details, and device type, so that your users get only the fields and sections that they want.")