Maybe you don’t want a tree control. Tree controls are best for users editing the hierarchy to an arbitrary depth (e.g., like when creating and moving file folders). I don’t know what the user task is here, but here’re some possibilities:
UI #1. Known Entity Selection
If the purpose of the UI is to select a known entity (e.g., a customer) for further work, then trees can be an awkward way to make a selection, requiring the user “drill down” through a lot of irrelevant information. Consider a search dialog where users enter any subset of:
The entity identifier (or substring)
Whether it’s a user or customer
Who it’s a user or customer of
This yields a list of matches for your users to select. This is best when your users know what they’re looking for, e.g., an entity name ADMVO. They can type “ADMVO” into the Search identifier blank and get the desired result. No need to think, “who is ADMVO a customer of again?” Nonetheless, it can also be used when your users can’t recall the identifier but know the entity is customer or user of someone else and they will recognize it when they see it. I’m assuming your users don’t think in terms of multiple levels of relationship such as “I know the entity I want is a customer of a user of Ford,” or “I need to retrieve all customers of customers of users of customers of GM.” That just seems human-infeasible.
UI #2. Network Exploration
If the purpose of the UI is to explore and edit the relations among entities, the UI depends on the structure of the relations. Your example suggests you don’t have a hierarchy at all, but a network structure of relations. This is the case if a given entity (e.g., Volvo) appears on more than one branch (e.g. it’s customer of Ford but also a user of GM, and also maybe a user at the System level). I suspect you users will be confused by trees where the same “leaf” appears on difference branches –it breaks the tree metaphor.
UI #2a If your network is relatively sparse (not a whole lot of connections between entities), then consider a node-link diagram that users can zoom, pan, and filter. Arrowheads on the links can show who is a customer/user of whom, and the shapes of the arrowhead (e.g., hollowed versus filled) or lines (e.g., solid versus dashed) can code the relationship type (user or customer). A tool palette provides pointer-tools to add new links, and any link can be selected for moving or deleting.
UI #2b If the network is too dense for node-link (many interconnections), then consider a square grid with entities listed across both the top of the columns and down the rows. Entities in the rows are potential users/customers of entities across the top. Cells of the grid code type of the relationship between each pair of entities. Users can pan and filter the grid. Your users can select any cell(s) and change the relations through menu commands.
For both #2a and #2b, your users can select an entity and open a window for it showing its details (attributes).
UI #3. Child Comparison and Edit
If the purpose of the UI is to study and edit the attributes of the children (users and/or customers) of a given entity, then consider a master-detail UI with three panes. The top pane provides attributes for a single entity (which may have been selected using UI #1). The next pane lists the users and their attributes in a tabular layout, and the last pane lists the customers and their attributes in a tabular layout.
Your users can view, compare, and edit the attributes of the users or customers directly in the tables. Put the tables in expanders and your users can show or hide customers or users as needed, much like a tree allows. Your users can edit relations by cut/copy/paste of selected entities from one child pane to another (including another in a different window for a different parent entity).
As in UI #2, users can select any entity in either child pane, and open a window for details on that entity (e.g., who are its customers and users).
