Some complications exist when defining multiple DN mappings that are used for the same request processor and the same source or target DN (or that have source or target DNs that are hierarchically related). The client request may not include enough information to disambiguate and determine the proper rule to follow.
Several solutions exist to avoid problems of disambiguation. If the client does not need to be able to see all mappings at the same time, then a new client connection policy can be created to use connection criteria that select the set of mappings applied to the client based on information such as the IP address or bind DN. Each client connection policy would have separated subtree views with separate proxying request processors that reference the appropriate transformation for that client.
Alternatively, if it is unnecessary to search under the o=sample base DN, then separate subtree views can be created in the same client connection policy. For example, one subtree view would be created for ou=east,o=sample and one for ou=west,o=sample. Each subtree view is then associated with its own proxying request processor, one for ou=east requests and one for ou=west requests.