Dev Log: August 11 Wrap-up

Overview

Spent most of the day wrestling with duplicate records in our lead intake flow. It started as a simple deduplication task but evolved into a bit of a back-and-forth between how the backend handles exceptions and how the frontend interprets them.

What I Worked On

Refining the Deduplication Logic

The main goal was to stop our CRM from getting cluttered with repeat entries. Initially, I was just looking at the user's IP address and email. If a match was found, the system would just update the existing record instead of creating a new one.

But as I dug deeper, I realized checking just the IP and email wasn't specific enough. Users might be submitting different types of forms from the same machine. I ended up expanding the query to include the form type as well. This way, we aren't accidentally merging data that belongs to two different workflows.

The "Merge" Headache

One thing that's always a bit finicky is making sure we don't accidentally wipe out data during an update. In my first pass, I was a bit too aggressive with overwriting values. I had to refactor the logic to pull the existing record, merge the incoming values into the current map, and then save it back.

// General logic for merging instead of overwriting
Map<String, Object> new_data = resource.convert_to_map();
Map<String, Object> existing_data = existing_record.convert_to_map();

// Ensure we keep the original ID while layering on new info
for (Map.Entry<String, Object> entry : new_data.entrySet()) {
    existing_data.put(entry.getKey(), entry.getValue());
}

// Update the persistent store
helper.save_changes(existing_data);

Communicating with the Frontend

The trickiest part of the day was dealing with how our custom exceptions work. Currently, our ApplicationException returns a generic error code to the UI regardless of whether it's a critical failure or just a warning. This was a problem because the frontend needs to know that a "duplicate found and updated" event is actually a success, not a reason to show a big red error box.

I implemented a sentinel string as a workaround. Instead of a human-readable sentence that might change later, I’m throwing a specific constant string. The frontend component is now configured to watch for this exact string; when it sees it, it treats the submission as successful and moves the user forward. It’s not the most elegant "pure" API design, but it solves the immediate bottleneck without requiring a full rewrite of our exception handling framework.

Wrapping Up

It feels good to have the lead intake a bit cleaner. It’s one of those things that seems small but saves the sales team a lot of manual cleanup work. Tomorrow, I might take a look at some of the logging around these updates—it'd be nice to have a clearer trail of when a record was merged versus created from scratch. Catch you then.