Your InsideSales.com system actively stores two basic types of Salesforce data:
This data is collected at various times during the package installation, as users are added or removed from Salesforce, and as dialer lists are generated.
The IS.com platform stores a small portion of user data to validate that reps are authorized to use the dialer tools, either as administrators or "basic" users.
When a user is given a dialer license, the first time they access any dialer functions they are required to perform an OAuth authorization process that generates a unique user ID token. After the IS.com system generates the token, it sends an API call to Salesforce to store the token string in the user's Salesforce profile in a custom field.
With the token string stored on both ends, InsideSales.com never needs to store the agent's actual username and password. All API commands transferred between systems use the token string as the method for authorizing activity.
If the user ever changes their password in Salesforce, it automatically invalidates the token string, and the user has to perform the OAuth authorization again to generate a new token. This prevents anyone from being able to use an outdated Salesforce password to access dialer functions.
Likewise, you as an administrator can go in and delete an existing token string in the user's Salesforce profile, which immediately nullifies that user's access until he or she runs the OAuth process. By default the InsideSales Authorization Token field is not added to the user layouts page in Salesforce, so if you want the ability to do this, you'll need to add the field to the desired layouts.
Other data stored includes the users first and last name, email address, phone number, and some basic permission settings about how the user is allowed to access data in Salesforce. We take these permission settings so we make sure those same restrictions to data are applied when the agent is working in the PowerDialer.
We also store some settings that are not part of the user's Salesforce profile. These include caller ID settings, call recording settings, and other dialer-specific items.
When your reps use Click-to-Call directly in Salesforce, no actual Salesforce object data is captured in the InsideSales.com database. The dialer does capture basic information about the call itself, such as the number that was dialed, how long the call lasted, and the relative start and end times based on the call recipient's time zone.
This information is captured in what we call an "impression," and is later passed to a Salesforce task within 10 to 15 minutes following the call. When the call data is sent to the task, the IS.com platform asks for the Salesforce task object ID to store for future reference. Thus, for Click-to-Call, the only information stored directly in the IS.com platform is the call impression data, and the synchronized Salesforce task object ID in the call impression database.
For dedicated PowerDialer mode, IS.com stores all object data for items compiled into a Seek or Domino list. Any fields displayed in an object layout will synchronize into a "facsimile" database stored in the IS.com platform.
This database is generated when the controlling user first installs the PowerDialer package. Placeholders are set for all objects, and fields within those objects, visible in the controlling user's Salesforce layouts.
Data is not physically added to the placeholders UNTIL a Seek or Domino dialer list is generated.
Our rationale for storing Salesforce object data is two-fold. First, we want the user experience in the PowerDialer to be as seamless as possible. Due to limitations in Salesforce API usage, it is not feasible to run individual API calls for each dial made. Thus, the dialer needs local access to record data.
By batch retrieving a large number of objects at a time and storing them first hand, we can render a near-perfect mirror of your existing Salesforce object layouts. This keeps the information and visual orientation familiar, increases user accessibility, and increases the speed of the system.
Second, the IS.com platform can use data stored in the "facsimile" database to optimize calling success. The performance-enhancing Neuralytics™ tools can adapt and update call lists on the fly. This gives your reps the best quality, highest-success prospects to call, increasing contact rates and qualified opportunities.
When you generate a Seek list, for example, the IS.com platform constantly refreshes the records in the list based on time of day, lead status, number of dials, and other criteria to optimize the calling order. These can be based on criteria you set manually, or using the platform's sophisticated algorithms that generate a NeuralScore™ indicator.
Once record data is added, it follows the standard data update process outlined in the call list flow.
Once objects are added to the IS.com database, they remain there until the original Salesforce object is deleted and purged.
If you wish to delete objects from the IS.com "facsimile" database without removing them from Salesforce, send a request to the InsideSales.com support team. They can work with you to establish which information you want removed, and set up a process to do so.
If there are specific object fields you do not want sent to the IS.com database, you can add these as individual field exceptions using the Manage Field Exclusions tool in your InsideSales tab.
This tool allows you to exclude any standard or custom Salesforce objects, or individual fields within those objects, from being sent to the IS.com database.
When a field is excluded, a "placeholder" for the field is still added to the PowerDialer layout page, but no data for the actual list objects will ever pass to it. When the user views a record, it will appear with the text "Data not available."
If you're concerned about data being stored in the IS.com platform, you have two basic choices:
While Option 1 is technically possible, you'll lose out on some of the most significant performance-enhancing benefits of the PowerDialer for Salesforce. If at all possible, we recommend setting up field exclusions as needed.