We’re now eight years into using Workday, and like many other Workday customers, we’ve found ourselves needing to integrate Workday with a variety of other systems. There are several iPaaS (Integration Platform as a Service) solutions out there—SnapLogic and Mulesoft being two popular choices for Workday integrations today.

However, when we began this journey eight years ago, these tools were nowhere near where they are now in terms of supporting Workday. Pre-built recipes, plug-and-play connectors, and other modern conveniences simply didn’t exist. But we still had critical integrations to build, including connections between Workday and systems like Banner in the early years.

Why We Chose PHP (and Continue to Stick with It)

Given where our strengths lay at the time, we chose to build our integrations using PHP. Over the years, this approach has grown into a robust framework that works well for us. While we periodically consider migrating to one of the modern iPaaS platforms, the cost, time, and effort required to make the switch has so far outweighed the benefits. We also piloted Workato for a couple of years but were unable to get enough internal buy-in, so we eventually moved away from it.

Today, most of our integrations remain PHP-based, with a few exceptions that use MS SQL Server. But the footprint of those is quite small compared to the PHP-driven work.

Our Integration Approach

When we need to pull data from Workday for downstream systems, we typically:

• Write Advanced Reports in Workday.

• Share these reports securely.

• Use the Web Services URL for the report, usually in JSON format because it’s easier to parse and handle in PHP.

For writing data back to Workday, we use the appropriate web services, packaging the data as XML and calling the WSDL URL documented by Workday.

We primarily store the retrieved data in MySQL, with some data in Microsoft SQL Server. Initially, we faced challenges implementing Workday Web Services Security (WS-Security) in PHP within the time constraints we had. To address this, we leveraged a Python package for the write-back process. Everything else remains in PHP, with Python handling only the callback to Workday.

This setup has worked reliably for us—and as the saying goes:

When all you have is a hammer (PHP), everything (integrations) looks like a nail.

We’ve essentially built a template-based approach:

• Copy a base PHP script.

• Modify report names, MySQL table names, and any necessary transformations.

• Use a standard template for XML packaging and call the Python script with the correct web services parameters for write-back.

While some integrations are more complex, our PHP proficiency allows us to handle them quickly and effectively. And with tools like ChatGPT assisting in documentation and commenting, development has only gotten faster.

Empowering Functional Offices with Control and Feedback

As our integrations matured, we identified two key needs:

1. Providing feedback to functional offices on whether integrations ran successfully.

2. Giving end users control over when integrations run and in which tenant.

This is where Google Sheets API  became a strategic part of our solution.

For example, our major/minor declaration integration writes its output directly to a Google Sheet and also pulls error reports from Workday’s import web services. The Registrar’s Office monitors these sheets and collaborates with the development team (I’m the primary developer on most of these) to address any issues.

Over time, we enhanced this approach by adding a “Control Sheet” tab within the Google Sheet. Here, end users manage integration parameters—like scheduling, start and stop dates, and tenant selection. This gives functional offices flexibility, such as stopping certain integrations during specific periods (e.g., halting the Financial Aid Period Record update after the first day of classes).

Scaling with MySQL and Managing API Limits

One challenge we encountered was hitting Google API limits due to the frequency and volume of integration runs. To mitigate this, we:

• Store control parameters in MySQL.

• Check for Google Sheet modifications between runs, pulling fresh data only when needed.

This approach significantly reduced the number of API operations and helped us avoid rate limit issues.

We’ve also extended this model to let functional offices maintain other operational data directly in Google Sheets. For instance, the Study Abroad Browser relies on data maintained by the Office of International Studies in a shared sheet. This requires a level of discipline on their part, but it provides flexibility and direct ownership of the data.

Optimization and Reliability

We’ve fine-tuned the process of writing to Google Sheets, and despite running hundreds of integrations daily, we rarely encounter API limit errors anymore.

One lingering limitation is that the Google Sheets API doesn’t provide a direct way to check when a sheet was last modified. (If you know a solution, please share!) To work around this, we use GAM to retrieve modification timestamps.

What Keeps Us Here

Honestly, this method has worked so well—and for so long—that it remains our preferred approach. Our PHP codebase is repetitive (in the best way), consistent, and easy for our web developers to understand. With support from tools like Gemini and ChatGPT, we’ve added detailed comments and summaries to make the code even more maintainable and accessible to a broader group of developers.

Some of these integrations haven’t been touched in years—they just run.

And sometimes, that’s the best indicator of success.

Note: I used ChatGPT to clean up the post and create the summary at the beginning