Клиент и подрядчик работают в разных порталах Битрикс24. Клиент ставит задачу в своём проекте, подрядчик переносит её в рабочий контур, уточняет детали в комментариях, потом сообщает результат обратно. Ручной маршрут, и в нём легко пропустить новую дату, правку описания или файл, который заменили в исходной карточке.
Есть более прямой путь. Приложение «Межпортальные задачи и коллабы» связывает задачи двух самостоятельных порталов Битрикс24. Сотрудники продолжают работать в привычных карточках, а связь между задачами не открывает доступ ко всему чужому порталу.
Полный двусторонний обмен нужен не всегда. Базовая схема проще: клиент создаёт и меняет задачи в согласованной области, а партнёр получает связанную карточку на своём портале. Обратную передачу включают только для тех данных, которые должны вернуться клиенту.
Односторонняя схема: клиент передаёт задачу партнёру
В односторонней схеме клиентский портал задаёт исходные условия. Новая задача в разрешённой области создаёт связанную задачу у партнёра. Изменения клиентской карточки передаются в рабочую копию в пределах поддерживаемых данных.
Область обмена выбирают конкретную:
- один или несколько проектов;
- рабочие группы;
- существующие коллабы;
- список ответственных сотрудников.
При отборе по ответственным приложение учитывает назначенного исполнителя, а не автора задачи. Это удобно, если обращения приходят из разных проектов, но их передают одной группе координаторов или нескольким специалистам.
Схема клиент → партнёр подходит, когда клиент задаёт объём работ, сроки и исходные материалы, а подрядчик ведёт исполнение в своей карточке. Клиентская задача остаётся точкой постановки, партнёрская — внутренним рабочим контуром.
В стандартный обмен входят название, описание, крайний срок, плановые даты начала и окончания, приоритет, теги и оценка времени. Очистка поддерживаемого значения тоже считается изменением. При одностороннем направлении внутренние правки подрядчика не возвращаются клиенту по умолчанию — это отделяет технические заметки от данных, которые видит заказчик.
Типовой сценарий: задачи на доработку сайта
Компания ведёт маркетинговые задачи в собственном проекте Битрикс24. Подрядчик получает только задачи из группы «Передано в работу». Новая задача с описанием, сроком и макетом создаёт связанную карточку на стороне подрядчика.
Клиент может дополнить описание или заменить файл — подрядчик увидит изменение в своей задаче. Распределение внутренних работ, служебные обсуждения и задачи между специалистами остаются на портале подрядчика.
Типовой сценарий: отбор по ответственным без общего проекта
Заказчик не ведёт отдельный проект для внешнего исполнителя: задачи создают разные подразделения. Для обмена выбирают нескольких ответственных на стороне клиента, и связанные задачи появляются у партнёра. Для зеркала можно указать проект-приёмник партнёра; если его не выбрать, задача создастся без проекта.
Двусторонняя синхронизация: обратное направление включают отдельно
Двусторонняя схема не даёт обоим порталам одинаковые права на всё содержимое. После сохранения сопоставления начинает работать направление клиент → партнёр. Обмен партнёр → клиент включается отдельными разрешениями:
- изменения задачи и поддерживаемых полей;
- файлы;
- новые пользовательские сообщения в чате связанной задачи.
Разрешения разделены, поэтому схему собирают под конкретный порядок работы. Можно разрешить партнёру возвращать изменения описания и сроков, но не передавать файлы. Или включить чат для согласований, оставив поля задачи односторонними.
Важный момент: если обе стороны одновременно меняют один срок или текст описания, содержимое не объединяется. Более поздно обработанное изменение может заменить другое. Поэтому у каждого возвращаемого поля должна быть одна ведущая сторона. Клиент задаёт исходный приоритет и желаемую дату, а партнёр после оценки возвращает согласованный срок.
Синхронизация находится в бета-версии и может работать с задержкой. Её не стоит делать единственным способом сообщить о критичном изменении срока — для таких случаев нужен согласованный канал уведомления.
Типовой сценарий: агентство возвращает согласованные сроки
Агентство получает задачи клиента через выделенный проект. Клиент ставит задачу с желаемой датой, а менеджер агентства после оценки уточняет плановые даты и крайний срок. Для этого включают обратные изменения задачи и поддерживаемых полей.
Типовой сценарий: подрядчик передаёт итоговые файлы
Подрядчик готовит материалы в своей задаче и передаёт клиенту финальную версию. Для этого отдельно разрешают обратную передачу файлов. Файл копируется на другой портал, если он доступен приложению и соответствует ограничениям прав, размера и типа. Если файл отсоединить от одной задачи, его копия в другой карточке не удалится.
Чат связанной задачи: границы передачи сообщений
Чат связанной задачи подходит для переписки клиента и подрядчика, но не становится общим чатом двух порталов. Передаются только новые пользовательские сообщения, созданные после включения настройки. Старая история не импортируется, системные сообщения не передаются.
Если сообщение отредактировали или удалили, уже доставленная копия не изменится. Для чата подходят короткие предметные сообщения: уведомление о новом файле, согласованная дата, запрос доступа. Решения по сроку и приёмке лучше формулировать отдельным сообщением.
Ошибки при выборе направления
Пять частых промахов:
- Сразу включить обратный обмен для всех данных, а потом выяснять, чья правка считается актуальной.
- Считать активацию связи началом обмена — задачи пойдут только после сохранения сопоставления и правил администратором партнёра.
- Выбирать задачи по автору, когда процесс зависит от ответственного.
- Ждать переноса старой переписки — в чат попадут только новые сообщения.
- Использовать двусторонний обмен для синхронизации пользователей и прав. Ручные пары сотрудников определяют, кем будут назначены зеркальные задачи, но права каждого портала остаются самостоятельными.
Частые вопросы
Можно начать с односторонней схемы, а обратную передачу включить позже?
Да. Направление клиент → партнёр работает после сохранения сопоставления. Разрешения на обратные изменения, файлы и сообщения чата включаются отдельно.
Можно включить обратную передачу файлов, но оставить поля односторонними?
Да. Разрешения независимы: клиент получает итоговые вложения без обратного редактирования полей.
Что будет, если клиент удалит свою задачу?
Связанная задача у партнёра автоматически не удалится.
Нужен общий проект для обмена задачами?
Нет. Область обмена задают по проектам, группам, коллабам или ответственным.
Итог
Односторонняя схема подходит клиенту и подрядчику, которым нужно передавать постановки между отдельными порталами Битрикс24 без взаимного доступа ко всему рабочему контуру. Двусторонний обмен имеет смысл включать для заранее согласованных изменений: дат, полей, файлов или сообщений. Перед запуском проверьте область обмена, роли зеркальных задач, владельца каждого возвращаемого поля, правила для файлов и чата — и прогоните тестовую задачу на двух порталах.
Top comments (0)