Geopointe

Data Security Practices

This document explains how the Geopointe application handles our customer’s data in order to deliver the functionality we offer.

Common Principles

Common principles that Geopointe adheres to are…

  • Geopointe runs natively in your Salesforce system, not on Geopointe servers.
  • Geopointe adheres to Salesforce’s data security model. A Geopointe user is only able to map data they have been given access to through the Salesforce Sharing Model. If a user cannot see a record in Salesforce, they cannot map it in Geopointe.
  • Geopointe adheres to Salesforce’s field-level security model. A Geopointe user is unable to see fields they would not otherwise see in the application.
  • All mappable data and geocode data is stored in, and stays in, your Salesforce system. With the exception of any items documented below, data does not leave a Geopointe customer’s Salesforce system. Explicit Administrator action is always required before data leaves Salesforce.com.

External Services

In order for Geopointe to fully operate, it must communicate with external services. All of this communication is facilitated through Geopointe owned and operated applications. We never send your data directly to any other third party service. The Geopointe Master Services Agreement further discusses our legal relationship with these 3rd parties as needed.

All communication with external services is always performed over an https connection using the latest TLS protocol, currently 1.2.

Endpoint URL
Description
https://api.geopointe.io Geopointe API endpoint
 

As Geopointe has matured, it has required us to build our own API to provide services to our customers. This URL must be available on your company network. We have submitted this URL to the major players in the corporate firewall space, but it could not hurt to whitelist this URL on your firewall if you have a whitelist policy.

There are some features or configuration settings that may require your company data to leave Salesforce.com and those are listed below. They are all disabled by default. They all require an Administrator to enable or setup.


Geocoding

Disabled by default. Geocoding is the process of converting an address to latitude and longitude values. This must be done to enable mapping functionality. An admin must define what Standard or Custom Objects they would like to map. The Admin then needs to tell us what the address fields are on these objects. We will query the address fields and then send them to Geopointe servers outside of Salesforce.com to get the latitude and longitude values. No other record fields or identifiable data is transmitted. Only the address fields. If an organization already has latitude and longitude fields, this can be used, and nothing will be sent to external systems for Geocoding.

A typical request looks like the following.
[{  
    address:{
        street: '123 Main St',
        city: 'Philadelphia',
        postalCode: '19107',
        stateProvince: 'PA',
        country: 'US'
    },
    properties:{
        recordId: '0011400001eJBQM'
    }
}]

Assignment Plans

Disabled by default. Assignment Plans allow your organization to define shape records (e.g. groupings of postal codes, states, or even shapes you draw on the map) and have those shapes compared, in mass, against a set of data you specify. The technical process is called Point-in-Polygon (PIP) analysis. The results of processing an assignment plan are updates to your Salesforce records that document what shape(s) a particular record falls within. It is a powerful feature for lead routing, territory management, service ticket routing and more. This feature is disabled by default, but is available for all Geopointe customers to utilize if the admin configures it. 

A shape can be defined in two different ways. The PIP process runs differently based upon the shape type.
  • GeoShapes are collections of shapes from our shape library. For example, you may have a shape called "Midwest US" that is a collection of 7 States. 
  • Ad-Hoc shapes are ones where the boundaries of a shape are defined by a user clicking on the map to build a shape or by your IT team loading in shape data to the Geopointe Shapes object.
Ad-Hoc shapes are processed entirely on the salesforce platform. Geopointe is able to do the math to determine whether a point falls within the boundaries of an ad-hoc shape. This is primarily due to the inherent simplicity of an ad-hoc shape. Most ad-hoc shapes created by our customers consist of a small number of vertices. The more complex an ad-hoc shape is, the bigger the impact on assignment performance. For most every customer, ad-hoc shapes are processed very quickly.

GeoShapes are processed a bit differently. Geopointe leverages its GIS infrastructure hosted at api.geopointe.io to perform the PIP analysis. This is primarily due to the hosted shape data being quite complex. For example, administrative boundaries typically follow land forms cartographically, requiring a large number of vertices to represent the shape. As an example, the western border of Illinois in the United States follows the Mississippi River. Illinois is a complex shape. To process GeoShapes, the PIP process is handled off the Salesforce platform using an API built by the Geopointe team. No data is stored outside of Salesforce during this process. The API simply receives a request and delivers a response. All requests to our APIs are signed by the Geopointe application for authentication purposes and the body of a request would contain:
  • A list of Shape IDs
  • A collection of Latitude and Latitude points
As you can see above, no customer or personally identifiable information is being sent outside of Salesforce. It is merely a list of shapes and a list of points allowing a response to be returned that explains how they relate to one another.

Thematic Layers

Disabled by default. This feature requires Geopointe to send data outside of Salesforce so it is disabled by default. An Admin must opt-in and enable this feature before any data is sent outside of Salesforce.com. 

Thematic Layers allow you to aggregate, group, and color your Salesforce data by geographic regions. This is a very computational intense operation that cannot be performed on the Salesforce.com platform due to technical limitations. It requires us to send some of your data outside of Salesforce.com to Geopointe servers. The data sent to Geopointe servers is as follows:
 
  • Latitude and Longitude coordinates of records used in the thematic layer.
  • Numeric field value used for the thematic map.
For example, a thematic map that aggregates the Account field Number of Employees by Postal Codes would only send the following data to Geopointe servers for each account returned in the Thematic Map Data Set filters.
{
  "lat": "40.720103",
  "lng": "-73.987872",
  "m": 56
}​
The data exported from Salesforce is configured by the Geopointe Data Set that drives the Thematic Layer. Only records returned by these Data Sets will be exported to Geopointe Servers. In addition to filters defined on the Data Set, only data the user has access to will be sent as controlled by the Salesforce Sharing Model.

The data sent above is ephemeral in nature and is destroyed after the building of a Thematic Layer is complete.

All final Thematic Layer aggregation data stored in an encrypted at rest database on AWS servers using an AES-256 key. Data is stored in a multi-tenant database.


KML File Hosting

Geopointe provides the ability to add KML files to the map. When creating a new KML Layer, the user is prompted to upload the KML file. This file will be upload to and hosted on Geopointe servers. This file is encrypted with a randomly generated customer provided AES-256 encryption key that is stored in a Protected Custom Setting. Geopointe has no way to access or view the content of the uploaded file. Only your company can access the file with the provided key, which is an automatic process when using the Geopointe application.
 

SpatialKey (Advanced Analytics)

Disabled by default, License required. This feature requires a special license from Geopointe before it is enabled. Admins must then also assign these Licenses to specific users before any data leaves Salesforce.com.

After Geopointe Analytics is licensed by the Geopointe customer, it provides a mechanism for pushing data to a 3rd party geo-analytics service, SpatialKey (www.spatialkey.com). This transmission is done via the Salesforce servers at the request of a licensed Salesforce user. This transmission is performed over an https connection using oAuth 2.0 for authentication. Prior to utilizing this feature, the Geopointe customer is made aware that their data will leave Salesforce.

When Geopointe Analytics is enabled an equivalent org record is created on the SpatialKey servers that include the Salesforce Org name and Id. A secret oAuth 2.0 refresh token is returned to the Geopointe application. This token is stored in a Protected Custom Setting and is not accessible to any users or apps other than the Geopointe application. 

Data is exported with an Apex Batch Job invoked by a specific user. This Batch job runs with the users permissions (Apex code keyword `with sharing`) and will only send data to Spatial Key the given user has access to. We also validate all Field Level Security access. At the start of the batch job the process will also use the Spatial Key secret refresh token using oAuth 2.0 to generate a temporary access token to be used during the duration of the data sync. This will ensure the data being sent from the Salesforce org can only be sent to the matching Spatial Key org.

Once data is sent to Spatial Key a user can launch the Spatial Key application. During this process the Spatial Key access token is used to generate a temporary short lived user access token using oAuth 2.0 to ensure only users of the Salesforce org can access the equivalent SpatialKey org. Once inside the Spatial Key application a user can only see data they have synced, matching their Salesforce.com record visibility.