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