Дамы и господа!

Сейчас проектируем довольно сложную структуру данных для крупного веб-приложения. Физически все описывается в таблицах довольно хорошо. Но есть один случай, который не могу решить даже на уровне алгоритмики или описания бизнес-логики. Буду рад любым советам и заранее благодарен.
Перехожу к конкретике.

Дано:
Есть 12 типов пользователей, каждый со своими обязанностями и функционалом. Каждый из них использует нашу систему для выполнения свое работы и для взаимодействия с другими пользователями. То есть, может происходить хранения информации и обмен информацией в соответствии с правами доступа к ней у участников. То есть каждый юзер логинится под своим логином/паролем, заходит в свой кабинет (account), наполнение которого определяется его типом. Там он заполняет формы и аплоадит свои документы (1). Кроме того, он может смотреть доступные документы других пользователей и расшаривать им свои документы для просмотра (2). Помимо этого есть еще много другого функционала, но это за рамками проблемы.

Важно: юзер может использовать систему автономно. Тогда он работает в своем кабинете и ему доступен функционал 1. Либо юзер может быть участником сделки - тогда ему доступен функционал 1 и функционал 2.

Чтобы стать участником сделки юзеру нужно создать сделку и пригласить туда других юзеров. Или принять приглашение другого юзера присоединиться к сделке. Для определенности скажем, что в сделке могут принимать участие от двух до двенадцати пользователей.


Проблема
Имеем юзер1 - юзер4, каждый своего типа.
Представим, что юзер1 и юзер2 являются участниками одной сделки сделка1. Юзер1 приглашает юзера2 в созданную им сделку и юзер2 принимает приглашение. Они начинают работать сообща, загружая в систему документы и обмениваясь ими между собой. Начался колоборэйшн - все хорошо.
В то же время: юзер3 регится в системе и приглашает юзера4 в свою сделку сделка2. И она также благополучно начинает жить своей жизнью, наполняясь их совместными документами.

На самом же деле, все эти ребята работают над одной сделкой (в реале). И наступает момент, когда им нужно объединиться в одну сделку, чтобы они могли взаимодействовать между собой и уже в четвером работать над документацией.


И тут собственно вопрос задачи: как реализовать интеграцию/синхронизацию сделок в одну!?

Еще немного деталей, которые объясняют сложность (по крайней мере, как мне кажется):
1. Сейчас рассматриваем пример с 2-я сделками по 2 юзера в каждой. В реале - сделок, которые надо синхронизировать может быть больше и участников в каждой может быть больше.
2. Каждый из участников может отправить приглашение присоединиться к их сделки каждому из участников других сделок и наоборот. В итоге может возникнуть ужасная путаница - кто к кому присоединяется и кто к кому нет.
3. Синхронизация означает, что все материалы юзера в старой сделки должны перейти в новую сделку. А что если на момент перехода юзера из сделки в сделку его документы уже расшарены другим юзерам и необходимы им для работы.

Ну и последнее. Технически такая синхронизация реализуется просто и быстро: один UPDATE. банальное обновление Id в таблице-связке юзеры-группа. Интересует именно логика. Не могу четко себе представить, как это все организовать в системе.


Прошу прощения за длинный текст и за абстракции.
Еще раз спасибо.

Сергей.