My name is Josefine and I’m currently working as a HR Generalist at Darwin Recruitment, where I’ve been for just over two years now. Before joining Darwin, I worked in similar positions at two other companies, one as a Payroll Assistant and the other as a HR Assistant.

One challenge we ran into recently was changing payroll providers. Our previous provider had become very slow when responding to issues and it started causing delays internally, so over the last few months we’ve been having meetings about moving across to a new system.

I’d probably say the most unexpected part was how difficult it can be getting people comfortable with changing systems they’ve used for years, even when everyone agrees the current one isn’t working properly anymore. A lot of people were used to the old processes, so naturally there was some hesitation around changing things.

To help with that, we tried to keep communication open throughout the process and involved different teams in discussions where possible. We also worked closely with the new provider during the transition so problems could be picked up early instead of later down the line.

Looking back, I think I would involve end users earlier in the testing stages and probably provide more practical training before implementation. I think that would’ve helped people feel more comfortable before the full rollout.

At CrewHR, we hooked up our scheduling tool to a client’s old network and suddenly got tons of complaints about the app being slow. We fixed it by adding some caching and an offline mode. My take-away? Next time I’ll run performance tests in the client’s actual environment first. Testing in real-world conditions really does avoid a lot of headaches.

Our GPS clock-in system just wouldn’t work on the rooftop sites at Truly Tough. Crews weren’t getting paid right because they couldn’t clock in. We finally added an offline mode and made managers sign off on all timesheets. That fixed the pay issues, though the staff were a little annoyed by the extra step. My advice? Test your gear in the actual field first. Getting feedback early saves you a ton of explaining later.

In my client work, I see many companies purchase an HR/payroll technology but not have the pre-existing systems to support them in the setup aspects. Because of this, often times they skip portions of the implementation thinking they’ll come back to it, and then years down the road, they are paying for modules they never set up properly, therefore they aren’t utilizing it. I see this with performance management (performance reviews), talent acquisition (the recruitment process), etc. If a company doesn’t have a solid sample of performance review questions, they move past that part. If they don’t already have drafted declination messages for candidates they are passing on, they skip that part. Then the magic of the automation is missed in many areas. I recommend clients work with a partner to help them implement (like an HR consultant) or have a member of their team that is being rated on the successful implementation as part of their role.

I haven’t managed HR system rollouts myself, but I saw a team’s new vacation tracker cause a real mess. It would approve time off without checking if someone was covering the legal hotline. They spent weeks manually tracking everything on a spreadsheet afterward.

The lesson I took was that you have to test these things with actual scenarios before going company-wide, like asking “who covers the phones if this person is out?”

The hardest HR-tech integration problem we faced wasn’t authentication or API limits, it was the mismatch between how people actually worked and how the connected systems wanted roles to be modeled.

On 365daysbooking, we built a staff management layer for accommodation providers. Owners could add employees, assign roles, and control what each person could do with properties, bookings, cleaning, repairs, and support workflows. The unexpected part appeared when this internal role model had to live alongside other operational modules and an Expedia integration. Our permissions were built around real team responsibilities, while the external booking flow expected a different data structure and a stricter sequence of actions.

We overcame it by treating roles as part of the business process, not just an access-control table. We mapped every role to concrete actions: who can edit property data, who can manage bookings, who can handle support, who can see transactions. Then we adjusted the data model and onboarding flow so staff permissions, property setup, and channel publishing didn’t contradict each other. It slowed us down, but it prevented a much worse problem: employees seeing the wrong data or being blocked during time-sensitive booking work.

What I’d do differently is prototype the role matrix before writing the integration layer. I’d put HR, operations, and technical stakeholders in the same room and test real scenarios: a cleaner reports an issue, support changes a booking, an owner updates availability. My advice is to validate permissions against daily work first, then integrate. HR systems fail when they reflect org charts instead of actual responsibility.

You know, everyone assumes the biggest headache in HR tech integration is the actual plumbing—connecting the APIs, getting the pipes to talk. Honestly? It’s almost never the tech. The real killer is semantic mismatch. You’ve got these legacy systems where the data is just… messy. Different departments use terms like “employment status” or “department hierarchy” to mean totally different things based on how they operate. When we tried to sync a legacy ERP directly with a new HR platform, it was a disaster. The whole implementation ground to a halt because of a cascade of sync errors.

We realized we couldn’t just force the new system to swallow the old, fragmented data. So, we had to pivot. We stopped treating this as just a technical integration and started building a data mediation layer. Think of it as a translator. It sat between the old and new systems, cleansing and standardizing those definitions before they ever hit the modern platform. It worked great—it kept the legacy data exactly as it needed to be for audits, but the new system actually got clean, usable information.

Looking back, if I had to do it again? I’d force a comprehensive data dictionary audit way before we even thought about buying new software. Here’s the truth: integration failures are almost always process failures. They happen because nobody sat down beforehand to agree on what the data actually represents. You can’t just write code to fix a lack of consensus. For any future project, my rule is simple: get stakeholders in a room and align on definitions first. Don’t just automate your existing silos; make sure the technology is actually supporting a unified business logic.

When we built the recruitment app at Tibicle, the integration that caused the most unexpected problems was calendar scheduling. Connecting automated interview scheduling with both Google Calendar and Outlook sounds straightforward. In practice, the edge cases multiply fast.

Different calendar permission levels across organisations meant the integration worked perfectly in testing and broke immediately in the client’s live environment. Their IT policy restricted third-party calendar access in ways we had not encountered during development. The automated scheduling that was supposed to eliminate manual coordination became a support ticket the first week after launch.

The fix required building a fallback flow. When the calendar integration hits a permission wall, the system sends a manual scheduling link instead of failing silently. The candidate experience stays smooth even when the automation cannot complete.

What I would do differently: test integrations against real enterprise IT environments earlier, not just clean development setups. Enterprise clients have security policies, firewall rules, and permission structures that never appear in a standard API sandbox. We now include an IT environment audit as part of every discovery workshop before building any integration.

That lesson came directly from this project and has saved us from the same problem on every integration we have built since.