My name is Zachariah Jia, and I graduated with a Bachelor's degree in Electrical and Computer Engineering at Calvin University. This summer I joined Soles4Souls as an IT intern on the Operations team. Soles4Souls is a global nonprofit that creates opportunity for people through shoes and clothing. We work to disrupt the cycle of poverty through different programs, such as 4Opportunity, 4Relief, and 4EveryKid.

This is my LinkedIn profile: linkedin.com/in/zachariah-jia. 

My first two weeks were about building a map. I was introduced to three platforms that I had never touched before. NetSuite for inventory and financial records, Wrike for project and task management, and HubSpot for donor and partner relationships. My first impression was that the hard part would be learning each tool. It wasn't. The hard part was understanding how data moves between them where a record is created, who touches it next, and what has to be true about that record before the next step can run. I spent my first week reading existing documentation and asking my supervisor to walk me through the full lifecycle of a single record from intake to reporting.

One of my assigned tasks was building a workflow automation in Zapier that keeps HubSpot and DonorDrive in sync. The automation pulls data out of DonorDrive and runs it through a sequence of steps (parsing the raw response, formatting fields, and filtering out invalid records) before updating the corresponding records in HubSpot. Zapier itself was easy to get started with. There was no formal training for it, so I learned it the way I learn most software: I opened it, clicked through every menu, and built small test Zaps to see what each trigger, action, and built-in step actually did before using any of them in the real workflow. 

I got stuck implementing bilateral sync between NetSuite and HubSpot in Celigo. The hard part wasn't getting one system to update the other; it was preventing an update loop, where a change written into HubSpot immediately synced back to NetSuite, which triggered another update to HubSpot, and so on. I used Claude AI to build the conceptual scaffolding, then checked each concept against Celigo's documentation and tested it on sample records. The idea that unlocked it: "bilateral" isn't one flow running in both directions. It's two independent one-way flows, with a matching key so each side can find its counterpart and a rule preventing each flow from re-triggering the other.

My internship was remote, so most of my communication with my supervisor happened asynchronously. Once a month we met in person: we had lunch, then worked side by side for a few hours. Those afternoons were very useful. Questions that would have taken a message and a wait were answered in ten seconds. It was also the setting where I raised the problems I was actually stuck on, rather than the cleaned-up version I would have written down. Between those meetings, I often worked from the library rather than from home, because the change of setting removed the distractions that made remote work harder to sustain. 

My other automation was a one-way sync from DonorDrive into HubSpot, covering constituents, transactions, and donations. The first runs produced errors in volume, invalid phone numbers, duplicate records, formatting mismatches, and field values rejected by HubSpot. I was responsible for making the workflow reliable enough to run unattended. Rather than fixing errors one at a time, I worked through them by category. I added Filter steps so invalid or incomplete records never entered the workflow, used formatting steps to standardize values, and corrected the field mappings where the two systems disagreed. After each failure type was handled properly, the workflow stabilized. It now syncs over 1,000 records for each object type every week, without manual intervention. 

Over the course of the internship, I built several system integrations using Zapier and Celigo. The Zapier workflow pulls Donor Drive data into HubSpot every day. The Celigo integration keeps NetSuite and HubSpot in sync, so whenever a record changes on either side, the other side updates as well. Before this, keeping the two systems current took manual work, and the data was out of sync in between updates for a long time. Now, the two systems stay current and up to date via Celigo.