How a simple map feature turned into a data pipeline, and beat the standard Salesforce map along the way.
Every firm I work with wants to see its work on a map. Where are our projects, our clients, our offices; where have we won, and where have we never broken in. TrebleHook, the construction CRM I work on, runs on Salesforce, and Salesforce ships a map you can drop onto a page. So this looked like a small job. It was not. This is the story of how a simple map turned into a data pipeline, told in the order it actually happened, including the parts that failed.
One thing to say up front, because it sits under the whole build. This map is a Lightning Web Component, Salesforce's current way of building custom screens, and I had never built one before I started. I'd worked in the older frameworks it replaced, so I knew the platform and I knew the construction business cold, but the framework, the mapping library, the geocoding, all of it was new to me. I built it while learning it, and I'll come back to what that meant at the end.
The first version was built on the map Salesforce gives you. It plotted client and project locations, with filters, a list beside it, and pins colored by stage. There was one problem I couldn't see yet. I had no information about where projects stored their own addresses, so I'd assumed each project simply borrowed its client's address. When the real details arrived, I rewrote it to use each project's own location, and to fall back to the client's only when the project had none. In the same pass I caught a mistake of my own: the map keeps a location as a pair of numbers, and I'd been reading that pair in the wrong format, which threw every coordinate away. Fixed.
Then the map went blank, and the error pointed at a column that didn't exist. This turned out to be a Salesforce quirk worth knowing. When an organization switches on the built-in state and country lists, the field that holds a state quietly changes its internal name. Code that assumes one name breaks on any organization set up the other way. So the map had to stop assuming and start asking each organization what its own fields were actually called.
The real turn came with a brand. A mockup arrived showing the map in a firm's own colors, and the standard Salesforce map can't be reskinned; the look of it is fixed. To get the branded design I rebuilt the map on Leaflet, a widely used open-source mapping library, with map imagery from a service called CARTO. It matched the mockup. It also exposed something the old map had been hiding.
Here is the thing nobody had noticed. A map can only drop a pin if it knows the exact latitude and longitude of a place. Turning a street address into those two numbers is a step called geocoding. The standard Salesforce map had been quietly geocoding every address on the fly, behind the scenes, so pins appeared and everyone assumed the data was "on the map." The new branded map made no such assumption. It plots only real coordinates that are actually stored on the record. The moment I switched, most of the pins vanished, because the underlying records had never been geocoded at all. The old map had been covering for empty data.
The pins were never real until they were made real, and most of the hard turns in this story come off that one line.
That single fact changed the job from "add map features" to "build the thing that makes a map possible at all." I added a background process that takes every address, sends it to a free US government geocoding service, and writes the resulting coordinates back onto the record, along with a new field to hold them. From then on the map drew from stored coordinates, and the pins were honest.
Getting there meant learning another Salesforce lesson the hard way. Even after the new coordinates field existed and held data, the map stayed blank. The field wasn't missing; it was invisible. On a locked-down product, a newly created field is hidden from users by default, and the person viewing the map genuinely could not see it, so the request for it failed and the map fell back to the path with no coordinates and dropped every pin. Two fixes: give people permission to see the field, and make the map steady enough to carry on when a field is hidden instead of falling over. On a tightly controlled system, a field can exist and still be invisible, and that quietly changes what you get back.
With honest pins in place, the map could finally earn its keep, and it grew into a set of tools that answer questions a firm actually asks. You can draw territories right on the map and get a scorecard for each one: win rate, pipeline, backlog, top market. You can pick a pursuit you're chasing, draw a circle around it, and instantly see the projects you've already won or built nearby, which is exactly the "have we done work like this, near here?" question that wins interviews. Hundreds of pins gather into neat clusters as you zoom out, and size themselves by project value. A slider plays the firm's history forward, year by year. Offices sit on the map as their own layer. None of that is possible on the map Salesforce hands you, which is the whole point.
One thread ran through the whole build, and it's the reason I don't believe in hands-off automation for work like this. The failures that mattered most were the ones only a person looking at the actual screen could catch. The blank map. An office icon that rendered as nothing, with no error anywhere to explain it. Tiles that were too wide, a header that just repeated the tab name, pins that never showed up. A coding assistant can write and deploy all day, but it can't see the screen, and it doesn't know that being close to a pursuit is worth money, or which project stages count as "won." That judgment came from knowing the industry, and it pointed the code in the right direction every time it drifted.
Now the honest part. No one has used this yet. It lives in a demo environment on invented data; the win percentages on screen are made up, a property of demo data rather than any real firm's numbers. The redesign from the latest mockup is built but not yet live, sitting on its own branch. The geocoding covers US addresses and skips the ones it can't make sense of. There's real work left before this is in anyone's hands.
And still, I'll say the confident part plainly. This is better than the map Salesforce gives you out of the box. The standard one can't wear a firm's brand, shows a list of raw coordinates instead of addresses, and hides empty data behind pins it quietly fills in on the fly. What I built is branded, honest about which records are really placed, and able to answer questions, about territory, proximity, and history, that the default simply can't. Adoption is still ahead of it. Being better than the default is already true.
The same honesty as the tools that share this story. I had never built a Lightning Web Component before this, and this map is one. I'd built on the older Salesforce frameworks, so I knew the platform and I knew the construction business, but the modern framework, the mapping library, the geocoding pipeline, the security model, all of it I was learning as I went.
It worked because of the partnership. I directed an AI coding agent and tested everything on the real, deployed map; it wrote and deployed the code and probed the system. As I said earlier, the failures that mattered were the ones only a person at the screen could catch, and that division was the point: it wrote in frameworks I couldn't yet write in myself, and I could tell whether it was right because I knew what the map was supposed to do and what the data meant.
This isn't "describe a vibe and ship it." I knew the shape of the thing from the start: that projects needed their own honest coordinates, that a firm cares about territory and proximity and history, that the standard map was quietly hiding empty data. Those calls were mine. The agent closed a real gap in the how, not the what. It's the same method I used to build the card and email tools, and the fact that it held up twice, on two different problems, is most of why I trust it.