1. Integration of GIS Functionality with Salesforce.com
Joe LaCombe
Indiana GIS Conference 2016

2. Goals
Indianapolis implemented new Customer Relationship Management (CRM) System
Service requests, requests for information, etc.
Integrate with the GIS – address validation, location validation, duplicate checks
Completely within CRM

3. Salesforce.com at the City of Indy
Allows taking service requests from citizens
A leader in CRM systems
Web-based
Cloud hosted
Customizable
Expandable functionality
About a year ago, the City of Indianapolis implemented SalesForce.com CRM system. That was a big step from previous CRM that was limited in functionality and was a desktop solution.
Besides arguably being a leader on the CRM systems market, the SalesForce.com had a few things that the City of Indianapolis went for. It’s a web based solution, hosted on a cloud, it’s customizable, functionality can be expanded to meet the needs of a client.

4. GIS Challenge Showing and validating locations of requests
Tools available from Salesforce (through their AppExchange)
MapAnything
geopointe
Others…
Mainly for visualization and analytics of data in Salesforce
Can’t be fully integrated with the City of Indianapolis GIS
One of the challenges of implementation of a system designed to take service calls from citizens is to determine the right location of the incident reported.
There is a number of tools available as SalesForce application plugins on SalesForce AppExchange market that allow users utilize GIS functionality.
!!! The problem with all of them is that they can’t be fully integrated with the City of Indianapolis GIS that was built and matured over the years.

5. GIS Challenge We needed more flexibility
Want to validate against our address database and locators
Want to use our basemaps
Want to use our spatial web services for additional mapping and analysis
Plugins and 3rd party tools did not provide this
Additional cost for maintenance/support
In details, those problems include inability to use Indy geocoders which is really the only source of information the city can really rely on.
It would be nice to use the maps and map services built for the City using ESRI products.
Can’t easily integrate with the City of Indianapolis spatial web services for retrieving additional spatial information about the location of a request such as
And it also adds additional cost to the maintenance of the application which is not high but could be “annoying” for the user. Another disadvantage of using third-party tools is that the maintenance of the tools would not be done on the premises of the Marion County which would delay the troubleshooting of any problem.

6. ESRI Maps for Salesforce
ArcGIS Online based application from ESRI
Uses ArcGIS Online to authenticate users
License is needed for each call representative
The best option, at least technology wise, at that time was to go with ESRI map for SalesForce which looked like a viable solution but the problem was in the cost.
The city would have to create a name user ArcGIS Online account for every person taking calls in Mayor’s Action Center MAC (plus probably some management team staff). Considering how often the MAC staff changes, that would be quite an expensive option.

7. Simpler GIS Solution Salesforce.com is a web solution
We have an existing citizen portal that does this
Plugin a component through iFrame
GIS iFrame component abstracts GIS functionality from RequestIndy and can be plugged in to the application
Communication using post messages
So we went with simpler solution.
Since the SalesForce.com is a web solution itself, why won’t we use that to our advantage and create a GIS component that would be consumed from SalesForce through iFrame?.. It will be abstracted from the main RequestIndy application and could be easily plugged in to the main SalesForce application and the communication between the 2 components could be done through post messages.
On the image at the bottom of the slide the simplified workflow would be following:
GIS iFrame loads and once it is ready to process data, it send a signal to the SalesForce app specifying that it is ready.
The SalesForce application send back the request type data that holds information such as type of address, validation parameters, and others.
Once the iFrame processes the request, it returns back message object with validation results.

8. GIS iFrame Technical Aspects
Salesforce is on secure domain, the GIS iFrame has to be on one too
The iFrame has to be on public domain
Connections to non-secure resource (map services, any other web services) have to be done through a proxy handler
Has to work on Internet Explorer 9+
Before we started development, few technical aspects had to be considered.
Since SalesForce is on secure domain, the iFrame has to be on secure domain.
The iFrame has to be on a public domain.
Since connections are secure, connection to non-secure resources (map services, any other web services) has to be through a proxy handler.
And of course, browser compatibility. It had to work in the default internet browser used by the City of Indianapolis Mayor’s Action Center.

9. GIS iFrame Functionality at a Glance
Address Validation – right address of an incident
Duplication Check – check against existing open requests for duplicates
Jurisdiction Check – make sure we maintain it
Spatial Analysis – retrieving additional spatial information about location
As we started development of the SalesForce GIS iFrame (as we called it), few other tasks were included into the list of functionality that should be implemented.
Besides address validation, we also needed to check every new request for:
Duplication against already existing open requests – to make sure multiple people are not reporting the same issue.
Jurisdiction check - to make sure the City of Indianapolis is responsible for particular type of service request in the location specified by user)
Spatial analysis - to retrieve additional information about the location of request

10. Address Validation Based on type of address Parcel/building/unit
Street
Park
Type of input
Manual address entrance
Manual intersection input
Click on map
First of all, address validation is the crucial part of taking service request from a citizen. As you see on the slide it is quite complicated.
Without too much detail, what needed to be considered is the type of address (parcel/building/unit, street, or park), as well as how the address needs to be entered (typing address manually, typing intersection manually, or click on map).
Workflows are different based on those criteria, including custom cases like fallback to street addresses for cases when parcel address could not be determined for a given location.

11. Duplication Check
Spatial component (proximity of service requests from each other)
Buffer
Same street
Temporal component (time passed between submission of requests)
Duplication check is done against 2 factors: spatial and temporal that are specified in the Request Type object sent to the iFrame from the Salesforce application.
Spatial component specifies the radius of the buffer within which the duplicates have to be looked for. Besides that, the GIS iFrame is also checking if potential duplicate requests are located on the same street.
Temporal component is to specify the maximum number of hours that can pass between submission of requests.
For example, for 2 pothole requests to be considered duplicates, they have to be located on the same street within not more than 528ft from each other and be submitted within 72 hours from each other.

12. Jurisdiction Check
Based on Maintenance Jurisdiction attribute of centerline (DPW vs INDOT)
Based on the city where the incident occurs (Indianapolis vs Speedway)
There are 2 types of jurisdiction checks to make sure that a request in the given location should be services by the City of Indianapolis.
The first one is against maintenance jurisdiction of the street where accident occurred. The maintenance jurisdiction is an attribute assigned to every street segment in the City of Indianapolis centerlines layer specifying who is responsible for the maintenance of the street. As an example, if the service request location for a chuckhole falls on a street with INDOT as maintenance jurisdiction, the City of Indianapolis should not take this request.
The second type of jurisdiction check is against the Excluded Cities within Marion County. For example “Heavy Trash Pickup” request is not valid if the location is in either Beech Grove, Lawrence, or Speedway.

13. Spatial Analysis Township Solid waste collection info Census
Voting district information
Closest intersection
Neighborhood liaison
Registered neighborhood organizations info
Other info…
The last but not least is the spatial analysis of the service request location. In order to help the City of Indianapolis to facilitate citizens, the GIS iFrame returns a lot of spatial information about the location of the request, such as township, solid waste collection information, closest intersection, neighborhood liaison, and other…

14. Application Look and Feel
Here is a screen shot of the application at a glance and a link to the iFrame component itself. As you see it is a simple design with a map and address input at the top but it holds a lot functionality in it.
URL link to the GIS iFrame for SalesForce.com:

15. Technology ESRI JavaScript API (Dojo) and existing web services
Few more words about ESRI Maps for Salesforce:
Technology
Technology wise, the GIS iFrame was built using ESRI JavaScript API and Dojo coupled with WCF REST enabled web services created for the City of Indianapolis over the years.
Few more words about the ESRI Maps for SalesForce.com, solution from ESRI that I mentioned in the beginning of the presentation. It was recently moved to mature support meaning that ESRI itself does not distribute it anymore and that it recommends using ESRI JavaScript API instead.
Reference:

16. Summary Utilized existing functionality and validation services
Promoted reuse of components
Simpler implementation
More effective integration between Salesforce and the GIS
Flexible for the future

17. Questions?

18. Thank You!