Context
Magdalene runs a 24/7 Network Operations Centre for telecom infrastructure. First line takes the service-affecting events as they land, triages them, and either resolves them or gets them to the engineer who can. The measure that matters is not how many tickets you touch — it is whether the engineer at the other end can close the one in front of them.
Partway through my time there the business migrated its case management onto Salesforce Field Service. Migrations of that kind are never a clean swap: two systems overlap for a period, process documentation lags the tooling, and the people closest to the work absorb the difference by hand.
The problem
Working cases day to day, I started seeing the same job represented more than once. The same underlying piece of work existed as two separate case records, created through different routes into the new system.
The consequence was not cosmetic. An engineer would work the job, then find they could not resolve the case cleanly, because the duplicate record was still open and still counted. The work was done; the ticket said otherwise. Queue figures reflected volume that did not exist, and the people closing the work were the ones absorbing the friction.
The failure mode that concerned me most was the quiet one. A duplicate that nobody names becomes a local workaround — you learn which record to ignore, you tell the next person on shift, and the knowledge lives in handover notes rather than in the system. That is how a defect becomes permanent.
What I built
1. Establish it was real, not anecdotal
The first job was to separate a pattern from a bad shift. I gathered the specific cases where the duplication had occurred, recorded how each record had been created, and identified what the duplicated cases had in common — so that the report would describe a reproducible route into the defect rather than a list of complaints.
2. Raise it formally rather than route around it
The tempting move on a busy shift is the workaround: note it in handover, warn the next person, move on. I raised it through the proper channel instead, as a defect against the migration, with the evidence attached. In ITIL terms this is the distinction between an incident and a problem — the individual blocked case is an incident; the mechanism creating duplicates is a problem, and problems need an owner, not a workaround.
3. Write the analysis for the people who could act on it
I produced a written technical analysis: what was happening, what triggered it, what it cost the engineers downstream, and what would need to change. It was written for Operations and Performance Managers — people who needed to make a call, not read a debugging log — so the emphasis was on impact and remedy rather than on how clever the investigation had been.
4. See it closed
The issue was confirmed and fixed. The analysis went to the Operations and Performance Managers as the written record of what had gone wrong and why.
Decisions I would defend
Raising it, rather than absorbing it
Raising a defect against a live migration you did not own, as first line, is not the frictionless option. It was the correct one. A duplicate-case mechanism that persists past the migration window becomes indistinguishable from normal operation, and by then nobody is looking for it.
Writing it up, rather than reporting it verbally
A verbal report gets fixed once. A written analysis survives the shift pattern, gets read by people who were not in the room, and can be checked against later. It also makes the finding attributable — which matters when the fix needs to hold.
Framing it as an engineer-blocking issue, not a data-quality issue
Described as "duplicate records in Salesforce", this is a housekeeping ticket that waits behind the migration backlog. Described as "engineers cannot resolve completed work", it is a delivery problem. Same defect, and the second framing is both truer and the one that gets it prioritised.
The result
- The duplication was confirmed as a genuine defect rather than user error, and fixed.
- Engineers could resolve cases against the work they had actually completed.
- A written technical analysis went to the Operations and Performance Managers, giving the issue a permanent record rather than a verbal one.
- The route into the defect was documented, so the same class of problem was visible for the rest of the migration.
Separately, during the same period, I designed a structured daily logging system for the NOC to improve shift-handover continuity and incident traceability — the same instinct applied to a different gap: if it only exists in someone's memory, it does not exist.
Why this is on an engineering portfolio
Because the useful thing here is not Salesforce. It is the habit: notice that the system is lying about the state of the world, prove it, escalate it through the channel that has authority to fix it, and leave a written artefact behind. That is the same discipline I apply to a production incident in my own systems — and it is most of what separates software that runs from software that is operated.
My role and stack
Role: Service Management Specialist — first-line incident management, 24/7 telecom NOC. Sole author of the investigation and the written analysis.
Systems: Salesforce Field Service, ServiceNow, Jira, PagerDuty, Excel. Framework: ITIL — incident, problem and change management.