I'm lucky in that the CMS we use at work happened to be headless, so a variety of people can use the CMS to pull data into their own projects. I just have to build the pipeline.
This project really required two interrelated search tools: an employee lookup directory, and an office search - both on one page. Results for each needed to show information from each list. For instance, searching for an employee would show details about the employee as well as the office where the employee works.
Office information had to be maintained in Salesforce. The Technology team supplied me with an endpoint for this data. The CMS also has an API for other data that needed to be searched. The challenge was bridging these endpoints.
I knew I needed both an unchanging and unique piece of data from each API so each data set could be matched. The Office ID was the perfect candidate, so I wrangled up the team to help me enter literally ever Office ID into the CMS.
With the data having matching IDs to cling to, I could then build the pipelines.
Now, I know that frameworks like Angular, React, RXJS, etc. are built for this kind of data management, but I did it in a pretty old-school way: jQuery and AJAX. I didn't even use Promises. I did it this way in part because I don't know of a way to leverage a framework like Angular inside of a CMS, and I didn't use Promises because many of our clients still use IE, and Promises are not supported.
One of the bigger problems at our company is that there's a ton of work but only two developers. This often creates a bottleneck. One of the ways I've tried to widen that bottleneck is to give various team members the tools to add content and images or make adjustments to these themselves.
A recent example of this is a simple newsletter. At first, it was a very, very long email. Since emails are difficult to code and limiting from a user experience perspective, I try to convince the business to turn the email into a teaser and land the user on a microsite where the content has more room to breathe.
A potential problem with this approach is that now some of the same content has to be maintained in two places: one in the email and one in the microsite. To solve for this as well as allow various team members to CRUD content and images themselves, I used the API.
So I created a separate CMS instance that would actually only serve as a means to push data to the cloud where it can be grabbed for both the email and the landing page.