Не стоит умножать сущностей сверх необходимого. Это я по поводу моделей ограничения доступа, временных записей, слияния и пр.
Налицо есть логическое противоречие.
Если мы говорим о проверке клиента на уникальность - это указание на единый справочник клиентов. И это хорошо. Но если при этом мы говорим, что подразделение А никак не должно знать о существовании клиентов, заведенных Б, - то это уже НЕ единый справочник. А свои, местечковые справочники А и Б.
И вот тут ответ должен дать бизнес - а что же он, собссна, хочет? Как нужно решать данное противоречие?
У меня, кстати, сложилось подозрение, что на самом деле проблема не в том, чтобы А вообще не знать о клиентах Б, а в необходимости разграничений где-то дальше - по платежам, балансам и т п.
Не слияние, ни временные записи здесь не помогут - при слиянии могут меняться реквизиты, заведенные в др. подразделении, что опять же раскроет секрет первому подразделению.
Я могу только предположить разрешение таких коллизий через администратора системы, имеющего доступ и клиентам А и к клиентам Б.
Да, и кстати - это не вертикальное, а горизонтальное разделение прав. Вертикальное - по столбцам, т.е. по реквизитам (в данном примере).

Nobody faults but mine... (LZ)