Steve Blackwell - 1 month ago
The inability to have proper address fields, that follow state/country picklists, on custom objects has been a real hinderance for us! We've had to code and build some really complex solutions to ensure enforcement of state/country values entered into custom object custom text fields is validated against the defined values that would otherwise show on all standard objects. This is a bit one for us to have!
Simina Roman - 1 month ago
That's exciting news!
For us, being able to add the same address block to custom objects as we can on Accounts and Contacts would be great. Also being able to add that address block a couple of more times on the Account and Contacts objects as sometimes some customers have more than 2 addresses (but not likely to have more than 4).
Saisai Wang - 1 month ago
Hi all, a feature inspired by this idea is up for consideration in the January 2020 round of Prioritization. Help us determine which features you want us to prioritize as we begin planning for Winter ‘21 and beyond. Visit https://sfdc.co/PrioritizeIdeas to access Prioritization.
Saisai Wang - 1 month ago
Hi all, thanks all for your voting and feedback. To follow up on my last post, we hear you and recognize the importance of this feature. We did some research during release planning. Through more resources uncovered, this feature is very complex considering introducing new compound field data type has dependencies on many platform features, e.g. custom index, formula, soql, apex. We also need to design strategically with Address being an individual object and they are supposed to cover all your use cases address related. With that, we unfortunately don't have a concrete timeline but we'll keep you posted for any progress we make.
Adam Cadman - 1 month ago
So, what you actually mean is that it's like formatting of numbers (another request that's been open over 10 years) - Salesforce doesn't really care about day-to-day use of SF, just about all the shiny new toys?
I am quite sure SF has the capacity to fix many of these small issues, and you'd get way more gratitude and support for these small tasks from us hard-working devs and admins than you will ever get from releasing the next big idea.
Tricia McGuire - 1 month ago
@MatthewHenry Thanks! You are too kind! I'm glad you commented as I wasn't very clear with my "requirements".
When you need Street 1, Street 2, and Street 3 (or Gate # or Dock # or Bldg#) fields to interface with a different system, you end up building a lot of extra fields on every object which utilizes an address. I'd prefer to have many more address fields available in an Address Object, allow each org to select the fields and the layout(s) they want for addresses, then add those as components to page layouts, etc. The rub would be the transition from the old concept to the new, but with a decent mapping tool I'm confident Salesforce could make it happen. Worst case, DataLoader!
Filip Poverud - 1 month ago
It is interesting to see how the need of more than a Billing and Shipping address has stroke the global Sales Force since 1999.
I know relational modelling is outdated, still an Address Object is benefitial for any Entity being used as the source or target in any communication link with an exchange of data.
We also see that customers are either extending their Entity objects with Text fields lacking the GeoLocation and we see that customers are extending their data model with a custom object working as an Address Entity.
I've even heard stories about customers enabling Field Services to address and access the Address object, however, never seen this in action.
Unless Dreamforce predict that we will go back to only two addresses as we did in 1999, I see no reason why anyone would haul this out any further :)