Systems architecture
Why a custom field should not become the source of truth for physical access
A convenience field can quietly become critical infrastructure. Here is how to recognize the risk before operational software starts depending on it.
July 2026 · 6 min read
A custom field is useful for storing information. That does not automatically make it authoritative. Problems begin when a system starts assuming that a manually maintained field represents the current state of something operationally critical.
Physical access is a good example. If a door code exists because a person copied it into a reservation record, the software cannot safely assume that the value is current, complete or even associated with the correct lock. The real source of truth should be the system that owns the lifecycle of that access credential, with other systems receiving synchronized representations of it.
The ownership test
For any important piece of data, ask one question: which system is responsible for creating, changing and invalidating it? That system is usually the authoritative source. Everything else is a projection, cache or convenience view.
- Who creates the value?
- Who can change it?
- Who knows when it expires?
- Who can prove whether it is currently valid?
Design for reconciliation, not hope
External systems will drift. Networks fail, webhooks are missed and human operators make changes outside your application. Reliable integrations therefore need reconciliation: a way to compare intended state with actual state and repair differences safely.
The principle extends far beyond access systems. Whenever multiple products share operational state, define ownership explicitly and make synchronization observable.