The change always starts with the same sentence: “let us add one more status to the filter, it is a small thing.” And it is small. The problem is that by the third month nobody knows how many times it was said.
Classic change management is built around code: development happens, a transport request moves it, the quality system tests it. In low-code flows, what decides production behaviour is often a definition — an iDataView, a service, a transfer project. A definition is as consequential as code, and it rarely gets the same discipline.
The build-up is quiet. Two definitions change in the first month, five in the second, and by the sixth nobody remembers which version is live. The threshold shows up in an audit or an incident review, the moment somebody asks when that filter changed.
Definition versions, inheritance and rollback
The mechanisms that answer it sit inside the product. On the iDataView side, passive and active versions are managed separately: you can inherit from the active version, save as a new definition and roll back the last save. BI view designs can be exported and imported as files, with source mapping in the target system. Development, quality and production system relationships can be defined, and system data copied to another system in a controlled way.
What a transport request carries, and what it does not
Generated ABAP code and DDIC tables move with a SAP transport request, and the request is checked for modifiable status. That is SAP’s own mechanism, and its scope is SAP objects. Definitions on the product side do not travel in the same request: a BI view is exported and imported as a file, and system data is copied over defined system relationships. Missing that distinction produces the assumption that the transport moved everything.
What the change audit record says
The record exists: when a definition changed and who changed it can be viewed. What it does not say is why. The team not defending its own decision three months later is the one that wrote the one-line reason at the time.
Mechanisms alone do not make a process. The arrangement that works in practice comes down to three rules:
- Do not change definitions directly in production. Changing a transfer project’s filter in production carries the same risk as changing code; the only difference is that undoing it looks easier.
- Write the reason next to the record. Who raised it, which scope it was changed for and what was tested fit into one sentence.
- Set the test scope by definition type. An output check may be enough for a report definition; a project that writes into SAP needs a small-volume run and a target table check.
The DDIC table and the definitions that depend on it
Two points deserve particular care. The first is the delete and recreate flow: it checks whether the table holds data, but that check is not an approval process, and whoever reads the warning rarely owns the data.
The second is that definitions depend on each other. An active iDataView can also be the source of an API service or a SQL transfer project, so a field change made for a report can break an integration contract unnoticed.
Which makes the most useful pre-change question an inventory one rather than a technical one: which other flow uses this definition? Next week, pick three live definitions and work out how many times each changed in the last six months. If the number surprises you, the thing to review may not be your development process but your definition process — and we can start from your current definition inventory.