Field Notes
Field Notes is the Nocona Consulting build log — what is actually being built, written down as it happens, with the metadata, the diagrams, and the decisions that did not survive first contact.
A screen flow swapped typed address fields for the Address component with Google address lookup. The suggestion filled Street, City, State and ZIP on screen, the deploy succeeded, every test passed, and the Lead saved with StateCode blank. What the lookup actually returns in province and country, how to map it to State and StateCode, and why an update needs the code alone.
A screen flow that replaces the Lead New action had three screens with allowFinish set to false. The footer rendered, empty, and nobody could get past screen one. Why allowFinish governs the Next button too, the blank screen input that IsNull never matched, and the connector that looped back and erased everything the user had typed.
The client renamed his lines of business before anything had reached production. Which API names to change and which to only relabel, renaming an Opportunity record type through the Tooling API without changing its Id, the 11 fields a non-admin could not see, and two deploy failures on the way to a check-only validation against production.
Builder prospects and homeowner service requests share a single Lead record type, told apart by a Customer Type field. The decision is sound and it is not free: picklist values the field had and the record type never enabled, REQUIRED_FIELD_MISSING on a builder insert, a conversion flow about to turn a builder's office into a job site, and an Opportunity that lands on the wrong record type.
A subflow tags a builder for nurture when the call outcome is Existing Installer. The first formula would not deploy because it touched a multi-select picklist. The second deployed, ran without a fault, updated every other field in the same assignment, and wrote null. How it was found, why getVariableValue could not see it, and the nested IF that fixed it.
Closed Won produced an Order and an install Work Order, and the dispatch board stayed empty, because a Work Order is not a thing anyone can schedule. Creating the ServiceAppointment in Apex rather than switching on ShouldAutoCreateSvcAppt, and the silent SaveResult that cost an afternoon on the way.
A warranty network's diagnosis checklist was planned as seven fields on WorkOrderLineItem. Two of them belong on the Work Order instead, because the trip fee is charged once per visit however many doors get diagnosed — and the question that settles it is cardinality, not the requirement document.
Closed Won on a construction bid has to produce a booked Order and an install job, and the install must never bill a second time when the crew finishes. Two independent automations cooperate through one standard field that neither of them owns: WorkOrderLineItem.OrderId.
A two-visit repair bills once, when the Work Order completes. A technician who taps Completed at the end of visit one invoices the diagnosis and nothing else, and the spring fitted on Thursday never reaches an invoice. The guard that stops it once the return visit is on the job, the status that had to exist before blocking anything was reasonable, and the case no guard of this kind can see.
Two dropdowns on the same screen flow, identical to the user. One is a record choice set. The other has to reach a Location through AssociatedLocation, which no record choice set can do — and the metadata element for the thing that can does not exist under the name you would guess.
Whether a garage door call is warranty or billable depends on who bought the door, not who owns the house. One extra lookup on Location is what makes that answerable — and one custom warranty date field that had to be deleted the next day.
Five deploy errors, one cause. A foundational custom field and its global value set were written, committed, and never deployed — and every later piece of work assumed they existed. A dry-run found in seconds what reading the source never could.
A test failed with DUPLICATES_DETECTED, so the rules were obviously set to block. They were not. Database.DMLOptions carries allowSave, but setOptions does not carry the duplicate-rule header — only the Database.insert overload does, and by default that overload does not throw when the save fails for some other reason.
With State and Country/Territory Picklists on, Lead.State holds Tennessee and Lead.StateCode holds TN. A Flow copying the wrong one into a restricted picklist looked correct, deployed clean, and would have failed every enquiry with an address on it.
A screen flow built its Request Type dropdown from a picklist choice set, which returns the whole value set. The record type on Lead allowed a narrower list. The form offered New Construction and the save rejected it — and one of three lines of business had no route into the org at all.
No such column 'BillToContactId' on entity 'Order' is a sentence you believe. Under API 67.0 user mode it also fires for a field that exists and that your profile simply cannot see — and sf sobject describe hides both cases identically.
Person Accounts are irreversible and NPSP is a managed package you inherit forever. The household model needs neither — but it turns Lead.Company into the whole problem, and there is an order-of-execution trap waiting.
A billing bridge filtered parts on IsConsumed = true, which reads like parts that were used. It means parts that came out of inventory. For a company with no warehouse it is false forever, and every spring would have fallen off every invoice without a single error.
Salesforce Location has a VisitorAddressId lookup to a real Address object. It looked like the right answer. Three DMLs, two records, and a circular delete later, plain fields won.
Three Opportunity stages carried forecastCategory=Closed, so open pipeline was sitting in the Closed bucket. Nobody spotted it in the UI. The metadata retrieve showed it in one line.
A multi-select picklist caps at 150 values, cannot be rolled up, joined or filtered properly, and there are roughly 390 US metro areas. Replacing one with a junction object, seeded from the Census delineation file.
Record types are for process. Customer kind is an attribute. The test that sent four Account record types to the bin while three on Opportunity stayed — and the two deploy errors either choice hands you.
The order I set up Doorvana's Salesforce org — CLI, SFDX project, baseline retrieve, Field Service enablement, the FSL managed package — and what bit me on each.
The single most common way a home services Salesforce org starts lying about revenue — and the object discipline that prevents it.
Next step
A 30-minute call. I will tell you whether Salesforce is the right answer for your shop — including when it is not.