For example, imagine a case where an object is created in database A, moved to the integrate state and replicated to database B. The object is controlled in database A by default. In database B the object is moved from integrate to released. By default, if the object is sent from database B to A, the object in A is not updated and remains in the integrate state. This behavior is intentional because database A "owns" the object. Without protection, a build manager in another database might move the object to the rejected state, even though in database A that object is included in released projects.
When a single component or application is being developed across multiple databases, you might allow some transitions that are made in a noncontrolling database to be applied to the controlling database. However, you might not want allow this transition. For example, you might allow a transition from integrate to released to be replicated back to the controlling database but not a transition from integrate to rejected or released to rejected.
During a DCM receive, if an object in the transfer package is controlled in the receiving database, DCM examines the status of the existing object and the status received from the other database. It checks the Receive Control Transitions DCM setting, and if the transition is allowed, moves the object to its new state. However, no other property of the object is updated and the object is still listed in the skipped objects report. The status_log attribute shows the original database that made the transition and also includes an entry for when that transition was applied back in the controlling database.