Alan Davies - 25 days ago
I want to remind you all of the email I received in November - see email from Saisai Wang, copied below.
Let's all keep the pressure on Salesforce to resolve this soon - they say they are working on it!
Tricia McGuire - 25 days ago
This may not be on the roadmap any time soon (based upon the "Latest Comment from Salesforce") but I'm still adding a comment. In addition to the aforementioned reason submitted by this Ideas's creator I also offer: By only offerring a "block" of standard address fields Salesforce severely limits the ability to interface with other systems. Due to the company-specific nature of the work we do, our multiple operations software applications are custom-built and maintained in house, and we use an internationally recognized ERP which also expected those fields broken out. A disproportionate amount of time and money was spent during our Salesforce implementation to make the system addresses work well together and to build the processes necessary to make custom address fields stay in synch with the out of the box fields. I would much rather have spent that time on feature implementation. Please break out the address fields into logical bits as suggested by @SachinSangole and @ThierryChaput!
SACHIN SANGOLE - 2 months ago
This will be really helpful functionality, helping to avoind duplicate address being created, garbage data being created etc.
Having standard picklist for State/Country will be a good addition.
minimally, will be good to have
State/Province (Picklist - 2 char code for US States)
Country (Picklist - 3 character international country codes)
Thierry Chaput - 2 months ago
Hi Saisai, Yes this will save 2 main issues for Admin.
When we need to create addresses, we must create several fields so we are not compatible and this makes difficult to copy an address from a contact or account and compare them. In addition we cannot benefit from the "Country/State" picklist configured and have to maintain separate global lists and validations rules.
There are different ways to manage an address using custom fileds. Each partner decides on a specific structure and it is a nightmare when we installed packages from different providers.
Openning this will definitely help...!
Alan Davies - 2 months ago
This is encouraging:
Hi @Alan Davies (Pinkelk Consulting Inc) thanks for reaching out and sharing your thoughts on the Address and Localization address entity. We are indeed comparing between leveraging the existing address and location objects vs adding address as a custom field type. When we first designed Location and Address objects, it was to serve Field Service in the short term, but there's definitely a plan to generalize it for all Salesforce use case.
We are currently working with our data modelers to evaluate both options and make a decision on which route we are going to pursue. We'll have a more concrete roadmap lined up once this is decided.
Alan Davies - 3 months ago
You want address fields on custom objects? Would being able to add child Location objects, each with it's own full Address object (with geocoding, State/Country picklists, etc.) work for you?
Salesforce already has standard Location and Address objects, but they only make them available if you license Field Service 'Lightning'.
For all those who think that Location and Address objects may meet their needs as an alternative to an Address data type, I've started an Idea for this:
https://success.salesforce.com/ideaView?id=0873A00000159mZQAQ - Make Location and Address objects (part of Field Service) generally available.
If you think it will provide a practical alternative to an Address data type, please vote for it.