I would solve it like this: I would design the workflow logic to traverse the CMDB hierarchy in a controlled, vertical direction, starting from the CI associated with the change request. Instead of evaluating all CIs at the same level or under the same parent, I would build a script or flow logic that climbs the CMDB tree upward, level by level. At each level, I would check whether an approver is defined specifically for that CI. If an approver is found, I would assign them to the change request and stop further traversal. If not, I would continue moving up to the parent CI until either an approver is found or the root of the hierarchy is reached.
To achieve this, I would use the cmdb_rel_ci table to ensure that the relationship traversal respects the correct direction—such as from "Depends on" to "Used by"—so it avoids pulling in sibling or unrelated CIs. I would avoid logic that fetches all child CIs of a parent, as that commonly introduces unrelated approvers from other applications. I’d encapsulate this logic in a Script Include or a custom Flow Designer action, depending on whether the process uses traditional workflows or Flow Designer. This structure would ensure that approvals are assigned only to the relevant owners based on the CI’s direct lineage, preventing unrelated application owners from being involved in the approval process.
