Custom development
The client told us the tax was calculating by product instead of by province. We tested that against all 2,335 order line items and it was not true. Six other defects were, and we priced each one.
01Key numbers
02The situation
The client arrived with a diagnosis already written. Salesforce, they said, was working by item product and not by the province of the client. That is a specific, testable claim, so we tested it before designing anything.
It was wrong. Across all 2,335 order line items, zero orders shipping outside British Columbia carried BC tax treatment. The reported symptom was real. The stated cause was not.
The real exposure was larger and in a different place. Tax rates were hard-coded in eight places, five of which were formula fields, and one province rate had been stale since April 2025.
Recognise this in your own org?
03What we built
A custom metadata rate table of 28 records, one per province and tax class, with effective dating and a registration flag.
Five of the eight places a rate was hard-coded are formula fields. A formula cannot query a custom object, but it can reference custom metadata. Custom metadata was therefore the only store that let those formulas stop carrying literals without first rewriting the whole engine in Apex.
The schema stores the statutory PST or QST rate separately from the rate actually applied, which is zero for Quebec, alongside a registration flag and effective dates. The Quebec rule stops being tribal knowledge and becomes a data row with a citation.
Switchover ran in five phases. Snapshot the tax sums across all order items, deploy, re-run, compare. Any delta is treated as a bug in the mapping, not as an improvement. A rebuild that changes a number silently is a rebuild nobody can sign off.
A change-request sign error understated one progress claim. The fix was written and tested and left undeployed. It changes the reported contract value on a customer-facing document, so the controller confirms first.
We will demonstrate any of these live, on the real org,.
The trigger flow watched a formula field. That field carries help text reading "Informational purposes only. Not used in calculations." It was in fact the entry criterion for the whole order-side tax calculation. Anyone reading the org to understand it would have been told the opposite of the truth by the org itself.
04Outcome
The rate table went to production on 9 August 2026. Six defects were quantified in dollars before any of them were argued about.
Tax sums across all order items were snapshotted before each phase and compared after. Any delta was treated as a mapping bug.
Keep reading
Every order had an address and none had coordinates. Once they were mapped, one account turned out to be 20% of the book and the default view was hiding another 35%.
Field crews were opening five or six systems before starting work, and a logging flow was telling them it had saved data when it had saved nothing.
Tell us what is broken. You get a written read on it within one business day, before any money changes hands.