Templates lower the cost of starting, but create a longer-term question: continued use makes local methods diverge from the source. Fields change, processes gain stages, and dashboards develop local definitions.
These changes are often evidence that the template is useful. If updating requires giving them up, users must choose between improvement and their business. Remaining at the first imported version, however, cuts off later source improvements.
An upgrade therefore needs to combine two valuable forms of change. For business configurations and dashboard templates, Teloa compares the original source, current local version, and proposed update to identify where changes came from, then checks their effect on existing records.
Why the comparison needs three versions
Comparing only the local configuration and the new version shows differences, but not where they came from. A field name may differ because the user changed it or because the source did. Those situations should not be handled by the same overwrite rule.
Each version answers a different question:
| Version being compared | Change to identify |
|---|---|
| Original source version | What was first adopted |
| Current local version | What the user changed after adoption |
| Proposed new version | What the source has since added or changed |
A three-way comparison helps distinguish changes that can be merged from conflicts, so the user does not have to reconstruct a configuration from six months ago by memory.
Suppose the source adds “awaiting additional conditions” while the local version already has “internal review.” Both may coexist. If both sides change the meaning of the same stage, a specific decision is needed rather than a merge by name.
The preview therefore needs to show objects, fields, states, and relationships, rather than just announce a new version. An upgrade changes the definitions used in everyday work. The user needs to understand its effects.
A valid configuration can still be incompatible with existing records
A new version can pass structural validation and still leave existing data without a valid meaning. Reducing the available states, deleting a field, or changing its type can all affect records already in use.
The current impact check reads the relevant history, identifies affected fields and record counts, and blocks adoption when an incompatible change would cause loss. The draft can remain available while the relationship between the data and its definitions is resolved. Completing an upgrade should not require discarding old values.
Archiving old records does not automatically remove their impact, because the history still needs to be understood. A stage no longer used for new work does not make past customer records in that stage worthless.
Configuration merging and data compatibility are independent checks. An upstream field addition and a local rename may merge successfully. Removing a state still used by historical records can lose meaning even without a configuration conflict. Three-way comparison identifies who changed what; record-impact inspection identifies what adoption would affect.
This takes more steps than reimporting, but lets customization coexist with updates. A business need not abandon local practice to receive improvements or remain on its original template forever to protect existing records.
Conditions can change between preview and adoption
After a user checks the preview, another part of the system may add or edit records. Having no impact a few minutes ago does not establish that adoption is still safe now. Adoption needs to check the current version and dependencies; an old preview cannot remain valid indefinitely.
When a new preview is needed, the original draft stays available. The user only needs to reconsider the effects that have changed. Adoption status is checked against the original receipt, so waiting or interruption does not make the same upgrade happen twice.
These choices allow an upgrade to accommodate ordinary waits and interruptions without requiring the user to watch the page throughout. The system retains the original intent and result, while the user chooses what to adopt. Each has a clear part to play.
New rules for ongoing work still need to be enabled separately. Accepting a better configuration does not mean agreeing to more background work and resource use. A configuration change cannot also make that execution decision.
Restoring an old template does not restore the business to the past
Restoring an old configuration still faces current data. Wanting a familiar method back does not mean recent customer activity, tasks, and artifacts should disappear. Restoration therefore still uses merging, preview, and adoption, including checks that the older definition can accommodate current records.
A template can remain a lasting source beyond its first adoption. Users can receive shared improvements and continue developing local methods. Conflicts must be exposed and resolved rather than decided for them by an update.