With the announcement this past Thursday (11/07/2019) that Salesforce was introducing a new “omni-channel” content management system cleverly named Salesforce Content Management System (CMS), we thought what better time than now to take a look back at a project that necessitated the use of the Salesforce CRM to bring content to life on a client’s public website.

The Initial Ask

Our client asked that we design and develop a brand new marketing website, one where they could not only list their services, news and blog posts, upcoming events, and job listings, but could showcase their staff and client directories as well. Using WordPress at the client’s behest, we set out to code the site; a bunch of custom post types, a few custom taxonomies, and we were on our way. A simple site? Maybe not, but nothing out of the ordinary.

The Proverbial Monkey Wrench

The site was launched smoothly and everyone was happy—we were happy, the client was happy—with one exception: the content managers. Those tasked with keeping client and staff information—hundreds of records–up to date had one major problem: They had to update content not only in Salesforce for their own internal records and systems, but in their WordPress admin as well. “If only there was a way to update a singular record,” they lamented.

The Conscientious Fix

Taking our typical can-do approach, we started to look at the problem—researching possibilities—until we settled on a direction: All data would be input into their Salesforce CRM and pulled into their WordPress website via the Salesforce Lightning Platform REST API. So with API documentation in hand, and their data architect’s email in pocket, we set forth to do just that.

The Desired Content

Step one was determining the data: what records were to appear on the website, what data existed in Salesforce, what data would need to be moved to Salesforce, and what custom fields would need to be created in order to do that.

Ultimately, it was decided that we would be pulling two types of sObjects, Accounts and Users to drive clients and staff, respectively. Several custom fields were going to be needed in Salesforce for both objects, including biography/description fields, social media URLs, and sorting. Other fields—such as first name, last name, or title—were able to be utilized as-is on the website. Most importantly, however, a field was needed to determine whether or not a record was to be displayed publicly on the website.

After some back and forth with the client’s Salesforce architect, all custom fields were created, and we were able to begin pulling data into the website.

The Painstaking Integration

Once all of the data points were set, we were able to begin coding out the API integration. Connectors were written to send HTTP requests to the Lighting Platform API in the form of queries using Salesforce Object Query Language (SOQL). This enabled us to pull data, sorting and filtering by department in the case of staff, by vertical, region, or status (past or present) for clients. This also allowed us to access individual records.

Not wanting to slow the site or run into a situation where data could not be displayed if Salesforce was down or could not be reached, we hooked into WordPress’s Transients API—their standardized method of temporarily caching data—to store results. However, as these transients by definition have an expiration date, custom code had to be written to allow cached Salesforce data to persist until the system was able to grab suitable information to replace it. This also included coding a mechanism to automatically re-authenticate the Salesforce Lighting REST API so that data from Salesforce was always available and to allow the client to re-cache out of date information at will via the WordPress admin using the Settings API.

FInally, after a few days of work building out queries and mapping data for all of our scenarios, we were ready to begin displaying content on the page.

The Pretty Permalinks

From there, we were able to add a custom template to WordPress and pull the correct Salesforce data to the correct page where appropriate. With this working, we finally had rendered, styled Salesforce content on the page. The resulting URL structure, however, left something to be desired. 

Wanting to replace URLs like “/team?sobject_id=5003000000D8cuI” with something a bit more appealing (i.e “/team/jane-doe”), we created a system to generate unique slugs (part of a URL or link that comes after the domain extension) for each record. Once in place, we then utilized WordPress’s Rewrite API to make those “pretty permalinks” a reality and, voilà, our Salesforce data was not only displaying on the pages we wanted, but with readable, SEO-friendly URLs to boot.

The Relational Data

Patting ourselves on the backs did not last long, however, as we still had a monumental task ahead of us. In moving the staff content off of WordPress and into Salesforce, we removed all the authors from the blogs. We needed a new mechanism to allow the client to tag not only multiple Salesforce Users to the blog post as author, but also “guest authors”—authors who lived neither within Salesforce nor within WordPress’s userbase. These guest authors would live within another custom post type.

This meant we had to remove WordPress’s default ability to add users as authors and replace it with a new input or custom meta box. This new multi-select input allowed the client to not only select multiple authors from the Salesforce data but from this “guest author” pool as well. To achieve this, we had to create a system to standardize both WordPress data and Salesforce data, displaying the data in the WordPress admin for proper attribution of blog authors as well as on the public side of the website. Using a similar approach, we were able to tie clients to press releases as well.

Once the correct blog posts were attributed to the correct Salesforce users, we then had to display posts attributed to that user on their page of the site. As these pages were made up entirely of information coming from Salesforce, we had to utilize custom WordPress queries to pull in the proper blog posts for a particular Salesforce user.

Following this, we then had to display all of that staff member’s clients on their bio page and vice versa. This required integrating a third sObject from Salesforce, AccountTeamMembers. Using this object as a pivot point, we were then able to tie the proper clients to the proper staff members, seamlessly displaying and crosslinking all of the client’s desired information across all of their desired pages.

The Site Search

Once all data was solidified, the content was in, and the relationships were set, we were able to move on to the final task: the integrated site search. This meant that when a user navigated to the search page and searched for a particular keyword, results needed to be displayed from both Salesforce and WordPress, co-mingled and sorted by rank.

This meant hooking into WordPress’s existing search system. First we grabbed WordPress’s results, then we searched Salesforce using their SearchQuery to search and return only the records that were needed on the site, mapped both types of records to a standard data format, merged them together, and sorted them by keyword frequency, finally displaying them to the end user.

The Finished Project

The resulting website provides a harmonious intermingling of both Salesforce data and WordPress content, allowing for a seamless experience for the end user as they navigate between content rendered from multiple sources, all while providing all of the rich features one might expect from a modern website.

The Bright Future

Since launching this integration in 2018, we have been tasked with multiple enhancements to the website utilizing this cohabitation of information. The site has grown into a multisite where multiple websites pull from the same pool of Salesforce data, displaying different information and rendering it in unique ways. We have added the ability for the end user to filter Salesforce Accounts without page reloads, and we are working on more expansive and complex search functionality. So while Salesforce begins to roll out their new features, we will continue coding away, using their platform as our own custom CMS. 

Want to learn more about Salesforce and how it can help you, click here.