I Tried to Merge Two Automations, Then Split Sales and Employee Administration Again

✨ GPT-5.6 Sol’s Summary

A record of designing an operations automation structure that could expand into inbound support and employee administration without losing the sales and text-message workflows already in production.

Two programs were already running

Inside the company, there were already two automation programs that had evolved in different directions.

One was a text-message-based annual leave management program built by my predecessor. It calculated each employee’s annual leave, sent reminders to use it, interpreted requests received by text, and carried them through approval or rejection. The Web app, backend, DB, and Android work phone already worked together as one flow.

The other was the public data collection and sales automation system I had continued to refine. It gathered facilities and contact information, connected them to Vox outbound calls, and handed them off to actual sales activity.

At first, I thought moving both projects into one repository would be enough to integrate them. But once I considered the features I wanted to add, simply combining folders was clearly not enough.

• inbound support connected to the existing outbound flow
• a flow that receives employee requests and hands them off to administrative work
• automatic generation and delivery of employment certificates
• access control based on employee, contract, and worksite information
• one operations screen for failures, approvals, retries, and audit records

The question changed from “How do I merge these two codebases?” to “Where should the work that will keep growing from here live?”

I decided not to throw away the existing program

Looking at the text-message-based annual leave program, I badly wanted to rebuild it. I could see an old structure and temporary settings, and there were many parts I wanted to redesign by today’s standards. It seemed as if taking only the requirements and moving them into new code would produce something cleaner.

But the more I inspected the materials, the clearer it became that the program contained things more important than its code.

• the actual annual leave results shown to employees
• how annual leave was calculated from employment start dates
• who received leave-usage reminders and when they were sent
• rules for interpreting text requests as dates and half-days
• the order of requests, approvals, rejections, and result messages
• how the Android work phone sent and received texts
• the screens and exception handling operators were already using

If I summarized all of that in a few documents and rebuilt it from scratch, the new code might be clean while producing different results for existing users. I could not erase a complete vertical flow my predecessor had built just because of my own design preferences.

So I changed direction. I would first reproduce the existing service as it was, preserve its screens and calculation results as regression baselines, and then replace the problematic parts feature by feature. The new system could not begin by deleting the old program. It had to bring that program into a larger structure without losing what it already did.

Sales and employee administration were not the same app

Putting the projects in one repository would create another problem if I also turned their DBs and Runtimes into one.

Sales automation handles public data, contacts, call targets, and sales results. Employee administration handles employee information, document issuance, annual leave, approvals, and messages. The two areas can appear together in one operations screen, but the nature of their data, their permissions, and the blast radius of a failure are different.

I did not want a sales DB migration to block an employee administration deployment, or an annual leave service outage to stop sales collection as well. Accounts and credentials, queues, backups, and rollbacks also had to be separated by type of work.

In the end, I decided to keep one repository but divide sales and employee administration into independent apps. The operations screen lets people navigate both apps in one place, but it does not read their DBs directly. Each backend remains responsible for its own data and permissions.

The outside could look like one integrated operations screen without the inside becoming one enormous service.

From outbound calls to inbound requests and administrative work

The existing sales automation was mainly an outbound flow that placed calls. On the 15th, I also spent a long time thinking about how to add inbound calls to it.

There was no need to process every request inside the calling system just because it arrived by phone. A call could be an entry point that receives a request and hands it off to the appropriate work. An employment certificate request should move into identity verification and document issuance, and the issued document should go through a separate delivery process. Even when the same request arrived through the Web or mobile, it ultimately had to converge on the same administrative workflow.

That was also why I chose to start with employment certificates. It was the first feature that could test, all at once, the flow operations automation needed: request intake, employee master data verification, document generation, approval, delivery, failure handling, and auditing.

The goal was not merely to build one feature well. The same boundaries had to remain reusable when other employee administration work was added later.

I could not rebuild the source of truth

The company was already managing employees, contracts, and worksite assignments in another system. The automation needed that information, but creating another employee master record on our side would soon leave the two systems out of sync.

The external system needed to keep owning the master data. Our side should read only what it needed and preserve it as a validated snapshot. The ability to modify the source record had to remain separate from the ability to process administrative events using that information.

The problem was that I had not yet confirmed the format of the actual download file or a stable employee identifier. If I called a number shown on the screen an employee ID, or wrote “Excel” without even checking the download feature, every design decision after that would rest on a false assumption.

So I left what I did not know undecided. It was a day when I produced many answers, but also a day when I kept revising sentences so I would not pretend to know what I did not.

Integration was not about combining folders

On the 15th, I wrote almost no code. I kept working through the project name, app boundaries, data ownership, the migration order for the existing service, and the role of the operations screen.

I wanted to respect the program my predecessor had built without freezing it in place, and I did not want to confine my own sales automation to its current structure either. It needed room to expand from the existing Vox outbound flow into inbound support, then into employee administration and document automation.

Putting two projects in the same folder was easy. The hard part was deciding what to preserve, what to separate, and where to begin expanding. The 15th was the day I started looking at two different automations as one operations structure.