Address as a Custom Field (Beta) Developer Guide

Address as a Custom Field (Beta) Developer Guide
Manage Custom Addresses as Component Fields (Beta)
Address as a Custom Field (Beta) Limitations
Configure State and Country Picklists
Apex Examples (Beta)
Metadata API Example (Beta)
REST API Examples (Beta)
SOAP API Examples (Beta)
Tooling API Examples (Beta)
PDF

Newer Version Available

This content describes an older version of this product. View Latest

Address as a Custom Field (Beta) Limitations

Before you add or manage a custom field of type Address, understand the limitations of this feature.
Available in: all editions.

This feature is a Beta Service. Customer may opt to try such Beta Service in its sole discretion. Any use of the Beta Service is subject to the applicable Beta Services Terms provided at Agreements and Terms.

Address as a Custom Field (Beta) has been enabled for a limited number of customers in Spring '22. Before you enable Address as a Custom Field (Beta), review the limitations.

Note

Here are the limitations for Address as a Custom Field (Beta).
  • The conversion of address data into custom fields of type Address from custom fields of other types isn’t supported.
  • To export data stored in custom fields of type Address, use API or SOQL queries. Bulk API isn’t supported.
  • To populate a custom field of type Address with imported data, use REST API. Bulk API and the Data Import Wizard aren’t supported.
  • For packages that contain a custom field of type Address, package deployment fails if Address as a Custom Field (Beta) isn’t enabled in the target org.
  • Process Builder isn't supported.
  • Fuzzy matching isn’t supported.
  • For custom fields of type Address, the State and Country components aren’t available for matching.
  • Search queries only support the data stored within the Street component of custom fields of type Address. The State, City, Postal Code, and Country components aren’t supported for search.
  • In Skinny Tables, you can’t select a component of a custom field of type Address as partition column.
  • When configuring search results for an object, custom address fields aren’t supported in Search Filter Fields (only available in Salesforce Classic). If you specify a custom address field as a Search Filter Field in a search layout, package installation and Metadata deploy() fails.
  • Custom fields of type Address aren’t supported in Lightning Web Components or Visualforce pages.
  • When using a custom field of type Address in a Data Integration Rule, the Country and State components are unavailable for field mapping.
  • Compound address fields aren’t supported in reports. To include these fields in a report, add the individual address components, such as street, city, state, and zip.
  • You can’t rename the labels for the individual components of a custom field of type Address.
  • The labels for the components of a custom field of type Address are always displayed in English (US), regardless of the org default language and user’s personal language.
  • You can localize the label of a custom field of type Address. However, you can’t localize the labels of the individual components within a custom field of type Address.
  • The word “Address” isn’t appended to the section label for a custom field of type Address. If you include the word “Address” in the field label, it’s included in the label for every component. For example, “Warehouse Address (State)” instead of “Warehouse (State)”. These labels are inconsistent with the label behavior for standard address fields.
  • You can experience slow load times when running reports that contain a custom field of type Address. REST API response times are also slower when creating records that contain data within a custom field of type Address.
  • When a custom field of data type Address is marked as read only or required in Setup, the changes aren’t reflected on the record Edit page.
  • The length of the GeoCodeAccuracy field for custom fields of data type Address isn’t consistent with Standard field of type Address.