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