Looking for to understand some of the address management strategy especially in regards to utilizing or leveraging geocoding and mapping with latitude (GPSE database field name) and longitude (GPSE database field name) values. I see the platform has the following scope regarding address schema:
- Account Address fields, GPSN, GPSE
- AccountAddress Address fields, GPSN, GPSE
- Contact Address fields, GPSN, GPSE
- ContactAddress Address fields
- Lead Address fields
- LeadAddress Address fields
- Order Delivery Address block
Questions
- With the usefulness of geocoding, why the inconsistency of not having GPSN & GPSE fields in the ContactAddress, Lead, and LeadAddress tables?
- The LeadAddress table appears to be unused (at least by default). Any clarification on its purpose or use in the system or how have others used this native table?
- The Account Address detail page does expose a map by default, is this possible to do for the Contact Address detail page as well?
- Is it possible to call the same geocoding that occurs for Account Address via a business process to say update batches of records?
- If I were to create custom GPSN and GPSE fields on the Lead table, is it possible to expose a map on the Lead detail page especially against those custom fields?
- In regards to the map feature, are there additional features to tab into for using the maps, such as routing?
Steve
Like
Dear Steve,
Please find the answers to your questions listed below. They are written respectively as were asked:
1. GPSN & GPSE columns exist in Contact and Account tables, but are not used. However, only latitude and longitude from AccountAddress are used for geolocation in Field Force.
Currently, in order to add/edit latitude and longitude you can use only Account Address detail, therefore, there are no such columns in ContactAddress, Lead, and LeadAddress tables.
Such functionality is likely to be added in future releases.
2. This table is used to transfer the information on lead's address, when it's qualified into Contact or Account.
3. Such additional development is sophisticated and is likely to be included in future releases of Field Force. However, in case you have a wish to realize it yourself, please see BaseAddressPageV2 schema in OSM package and also AccountAddressPageV2 schema to use as a base for new functionality.
4. Yes, you can use business process to update batches of records. Feel free to build it up to your needs.
5. Please see answer 3.
6. Please check the article for more details on how to to build a route for sales representative: https://academy.bpmonline.com/documents/sales-enterprise/7-10/how-build…
Thanks Anastasia. Quck follow-up questions
2. Are you implying LeadAddress table,a temporary or working data table?
4. So the I could reference the map objects via script task correct?
Steve
Dear Steve,
2. LeadAddress table is a working data table.
4. You can address tables in the data base from script tasks. Therefore you can address a table to obtain latitude and longiude. However, please note, that map processing logic is written in javascript schemas.
Hope you will find the answers helpful.
Anastasia
Dear Steve,
2. LeadAddress table is a working data table.
4. You can address tables in the data base from script tasks. Therefore you can address a table to obtain latitude and longiude. However, please note, that map processing logic is written in javascript schemas.
Hope you will find the answers helpful.
Anastasia
2. Just so I understand the workings under the hood as I am curious. The table is used to migration a lead address to a contact or the table is usused to collect additional addresses that also can migrate as additinal contact addresses. Am I following?
4. Right, the map logic is in javascript, so there is no direct or reuse of the code for say a business process correct? I was hoping to leverage the current map resouces. I would have to utilize some thing else in the business logic to replicate the map logic to get lat and long on my own.
Steve