Salesforce API & the Database

Background Information

This section of the help guide is for admins that want a better understanding of how the PowerDialer interacts with your Salesforce database, particularly for exchanging data. This may be relevant if you have particular security concerns for data passing between systems.

Feel free to skip ahead to the Installation section if this isn't applicable to you.


Content covered includes:

  • The baseline settings for the API
  • Product installation and how the PowerDialer for Salesforce builds off current Salesforce systems
  • The database synchronization process
  • Generating dialer call lists
  • The actual user call process, and how activity data is passed back to Salesforce.

Basic Salesforce API Principles

Much of the information in this section has been taken from the Salesforce Developer documentation, found at:

By default, incorporates a SOAP (simple object access protocol) API into its database platform. Any application running on the platform (including the Salesforce CRM) has this feature enabled, unless a system administrator specifically disables it. Like other Salesforce AppExchange applications, the PowerDialer for Salesforce uses the API to interact with Salesforce objects and records.

The API actively "listens" for actions initiated through the API interface. When a request comes through the API, Salesforce verifies that the request is coming from a valid source, performs the request, then sends back any information needed to complete the transaction.

Key Concept

The most important rule to remember regarding the Salesforce API: Client applications (such as the PowerDialer for Salesforce) that access your organization’s Salesforce data are subject to the same security protections that are used in the Salesforce user interface.

Quoted from the Salesforce documentation:

(begin Salesforce material)

Client applications must log in using valid credentials for an organization. The server authenticates these credentials and, if valid, provides the client application with:

  • a sessionId that must be set into the session header so that all subsequent calls to the Web service are authenticated
  • a URL address (serverUrl) for the client application’s Web service requests"

. . . . continued . . . .

"An organization's Salesforce administrator controls the availability of various features and views by configuring profiles and permission sets, and assigning users to them. To access the API (to issue calls and receive the call results), a user must be granted the 'API Enabled' permission.

"Client applications can query or update only those objects and fields to which they have access via the permissions of the logged-in user."

. . . . continued . . . .

"When users log in to Salesforce, either via the user interface, the API, or a desktop client . . . Salesforce confirms that the login is authorized as follows:

  1. Salesforce checks whether the user’s profile has login hour restrictions. If login hour restrictions are specified for the user’s profile, any login outside the specified hours is denied.
  2. Salesforce then checks whether the user’s profile has IP address restrictions. If IP address restrictions are defined for the user’s profile, any login from an undesignated IP address is denied, and any login from a specified IP address is allowed."

(End Salesforce material)

In accordance with standard Salesforce security provisions, logs in to the API using an OAuth security token generated and authorized by a system administrator, or where applicable, a username and password for Professional edition users.

API Security and Access

When using the Salesforce API, most administators are primarily concerned about ensuring that only authorized systems have access. To this end, employs security measures to ensure only authorized services can access a client’s API.

First, to be listed on the Salesforce AppExchange, a program must pass a Salesforce developer audit to ensure that the code is valid, and meets baseline security provisions for connecting through the API. One of those provisions is that the code must include a function that specifically gives the system administrator the option to allow or disallow the application from connecting to their system.

When the PowerDialer for Salesforce is installed, the sysadmin must specifically grant the application access to the API. If given permission, Salesforce responds in one of two ways, depending on which edition of Salesforce is being used.

For Enterprise and Unlimited editions, the Salesforce system sends a security authorization OAuth token to the requesting program. This token is a data string that uniquely identifies the requesting service, and "fingerprints" which Salesforce administrator generated the token. From that time on, any third-party programs must include the OAuth token to connect to a Salesforce system. Any requests or actions that do not include the OAuth token will be blocked.

Salesforce Professional edition, on the other hand, does not directly use the OAuth token method. Instead Salesforce requests the sysadmin’s user name and password as authorization to use the API. If the third-party application cannot supply a valid Salesforce Professional username and password, Salesforce blocks access to the API. As part of this process, system administrators for Salesforce Professional Edition are required to update the Network Access policy in Salesforce to specifically trust connections from an IP address range linked to’s platform.

Without making this change, Professional edition users would have to include their OAuth token string at the end of their password each time they logged in, a situation most users would find tedious. This circumstance does not apply to Salesforce Enterprise and Unlimited editions, as they use the default OAuth token method.

If a sysadmin later determines that API authorization needs to be revoked, Enterprise or Unlimited users have the ability to clear the current OAuth token, effectively cutting off all API access. This can be done in the Personal Setup menu in the Salesforce CRM, using the "Reset My Security Token" action.

Salesforce Professional administrators can revoke API access by changing their system password. Through these methods, admins ensure that only programs specifically authorized to use the API can access it.


To ensure that data passing between services remains secure, all transactions to and from the Salesforce API are transmitted via secure socket layer (SSL) using 256-bit encryption.

IP Address Range

Finally, a Salesforce admin can specify a set of IP addresses from which all API functions must originate. Any actions that originate from an IP address outside that range, even if the system supplies a valid security token or user login, are automatically blocked.

To ensure security on both ends, employs an active token requirement for all of its systems as well, and has the ability to limit access by IP address.

Connecting the Databases

Clients regularly ask how the PowerDialer accesses their existing Salesforce database, usually with the intent of identifying security concerns over data—they don’t want to risk employees accidentally seeing data they shouldn’t, they’re concerned about exposing data to an outside source during transmission, or they're concerned about the possibility of data being unnecessarily altered by the PowerDialer system.

The easiest way to think about this question is to understand that The PowerDialer never directly touches a single piece of your data within the Salesforce database.

What it does instead is make a temporary facsimile of the Salesforce data, by requesting information through the API. The PowerDialer then performs all of its work within the "facsimile" database, and sends updated record data, call results, and activities back through the API to Salesforce. The PowerDialer uses this facsimile system to ensure that it only touches the data and components it needs to function, and no more.

Data Hierarchy

When the PDSF is first set up, it looks at the current record fields and object layouts available to the user who performed the installation. It then creates a facsimile copy of those fields in a working database, and builds temporary object layouts that match those in Salesforce. This allows the PowerDialer to mirror users' existing workflow, easing the transition for using the software, while remaining as non-intrusive as possible.

The key to this process is based on a simple hierarchy—information in Salesforce takes precedence over information in the PowerDialer. If a Sysadmin updates a set of security permissions, adds new database fields, or alters a record layout in Salesforce, the PowerDialer will not receive those updates until the Sysadmin instructs the PDSF to synchronize them manually, or runs its once-a-day synchronization between the two systems.

Access User and Layouts

Another key to this process is what we refer to as the Access User. When the PDSF is first installed, the initial security and layout parameters are based on those of the Salesforce user who performed the install. This user is designated as the Access User.

One avenue for securing the database connection between the two systems is to limit data access and permissions for the Access User. Sysadmins can also change the designated Access User in the PowerDialer administrative tools.

You can also limit access by updating the Salesforce record layouts assigned to the Access User. During installation, the PowerDialer creates an entry in the facsimile database for every field available to the Access User, even if some of those fields are not displayed on the Access User’s Salesforce layouts. These replicated fields are based on Salesforce’s lead, contact, and account objects. However, because the PowerDialer exactly matches the Salesforce record layouts, any fields made unavailble to the access user's layout(s) will be unavailable in the PDSF.

The Access User can only see data they are allowed to access in Salesforce, AND those fields are contained in their layouts. All other users can only see fields in their respective layouts, as long as those fields are a subset of those accessible by the Access User. Any fields not accessible by the Access User will never appear in the dialer interface, or be copied to the PowerDialer’s facsimile database.

Once initial settings are established, the PowerDialer does not re-check the permission settings and layout options unless the Sysadmin instructs the PDSF to do so. These actions can be performed in the Manage Users link in the InsideSales tab’s administrator menu.

When a user opens a list of names to call, the PDSF looks at the assigned Salesforce object layout for that user, then uses the matching replica of the layout specifically built for the dialer interface. This replica layout resides solely on the server; it has no effect on the existing Salesforce layout. As users actively work in the system, the PowerDialer will check each record’s time stamp to ensure that its information is up-to-date before calls are made. If it has been longer than one hour since the last update, the dialer “pulls in” the record’s information from Salesforce before any new call activity starts. After calls take place, the PDSF automatically sends back completed call Task information, batched together in 15 minute intervals.

Initial Setup Process

During the PowerDialer™ for Salesforce package installation, the tool first prompts the Sysadmin to allow communication through the Salesforce API.

Once authorized, the PDSF first retrieves some basic information it needs to set up facsimile database system—the User ID, Organization ID, and Organization Name as listed in the Salesforce database. Once passed in to the facsimile database, the PDSF continues to build out.

First, creates a unique account on its internal systems linked to the client's organization. This account is where the PowerDialer's API calls and functions originate.

Once the basic skeleton of the database is created, the PDSF then sends a request to retrieve the Salesforce OAuth token, if using Salesforce Unlimited or Enterprise editions. The Sysadmin will receive a second notification, asking permission to send the OAuth token back. When the PDSF receives the token, it recognizes that it is now authorized, and begins building out the rest of the framework.

At this point the PDSF requests user account information from Salesforce--names, User ID, permission settings, layout assignments, and so on. Next it scans the current Salesforce database and creates a duplicate entry in the facsimile database for each field it sees related to the Access User’s lead, contact, and account object layouts.

Once the mapping process is complete for both users and data fields, the PDSF creates a second security token for its own API, and sends it back to Salesforce. This token allows Salesforce to reciprocally communicate with’s API, to ensure data security on our end.

When Salesforce receives the token back, the initial setup process is complete. At that point the Sysadmin can start managing the PowerDialer services, lists, users, and so forth using the InsideSales tab within the Salesforce CRM.

PowerDialer Management

Once installed, the PDSF creates a custom "Tab" location in the Salesforce CRM. If this new tab is not visible, you may need to click the All Tabs link in the CRM (the “+” sign at the end of their existing tabs). You can likewise add the InsideSales tab permanently to the CRM task bar through the Salesforce tab setup options.

Call Lists and Database Organization

The PowerDialer™ for Salesforce provides two methods for initiating a call action:

  1. As a one-off click-to-call directly from the Salesforce CRM.
  2. Through the creation of dedicated lists initiated through the PowerDialer interface.

Dedicated lists can be created as a static list of non-repeating numbers (Domino lists), or as an actively-updating, dynamic list (Seek lists). The process of creating lists is covered in the PDSF admin guide here.

Both types of lists use database management principles to prioritize calling actively, and set active targets and metrics. The diagram above outlines the basic data exchange that takes place when a dialer list is launched. This diagram assumes that a user or admin has already created the list in question, by building out a criteria-based query using the PowerDialer list management tool.

When your or another agent launches a list, the PDSF first sends the Salesforce organization ID and dialer list ID along with's security token (including the token validates that the requested action is allowed).

Next, the PowerDialer platform verifies which list is being targeted, and requests the saved list settings from Salesforce. Once the list settings are successfully retrieved, the PowerDialer sends back a separate relational list ID from the facsimile database. Once the list IDs are mapped between systems, the PowerDialer requests the Salesforce record IDs that meet the previously-defined list criteria.

Once all of the record IDs are compiled into a list, requests the record data for a small batch (50-100) of those IDs. Salesforce again verifies the request, and returns the requested data to the dialer. After receiving the data from Salesforce, the PowerDialer renders the information for the user.

Call Activity Flow

Before the PowerDialer displays any information, it first performs a cross-check with Salesforce to see when the record was last synchronized in the facsimile database. If more than an hour has elapsed since the record was synced, the PowerDialer pulls in the record data again, to ensure the agent is seeing the most up-to-date information.

Once the PowerDialer pulls the current record data, it displays the information for the user. At this point, the user does whatever work needs to be performed.

Once users finish working the record, they have the option to either save and move to the next one in sequence, or leave changes unsaved and move on. If a user chooses to save, all updates to the record content are saved immediately back to Salesforce via API immediately.

While record-level data is sent immediately, completed call activity will be sent later, attached to the primary record as a Salesforce task. This information includes dial impression and other call data. This data may take up to 15 minutes to be attached to the record. See the Activity Update section for more details.

After the user moves to the next record, the process repeats.

Post-Call Data Push

We mentioned in the previous section that call data generated by the PowerDialer--call time, dial counts, and call recordings--are not immediately transferred to Salesforce. Instead, the PowerDialer sends this data through the Salesforce API batch data process at recurring intervals.

The PDSF uses Salesforce’s existing Task object, and adds custom fields to capture call log data. Every 15 minutes the PowerDialer compiles the current call log data, bundles the task updates together, and sends them as a batch to Salesforce.

We designed this batch process because Salesforce places a limit on the number of API calls that an organization can use within a 24-hour period. The batch process reduces the number of required calls.

When a task batch arrives, Salesforce re-attaches the tasks to the correct parent records (leads, accounts, contacts, etc.). This methodology also allows you to track call data directly in the Salesforce report engine, leveraging the power of those tools.

Release Notes

Find our most recent release notes.


Our community forum is coming soon.

Advanced Training Guides

Advanced training for the PowerDialer for Salesforce.

Have questions?

We're happy to help. An expert is just a phone call away.

(866) 593-2807

Mon-Fri 6-7 MST

Back To Top

© 2004–2014, Inc. all rights reserved. Use of the service and this Web site constitutes acceptance of our Terms of Use and Privacy Policy. technology is protected by the following United States Patents: 8078605, 8325738, 8352389, 8510382, 8566419.