Вернуться к списку Вернуться к статьям
Статьи

Какие поля задачи передавать между порталами Битрикс24

Между двумя порталами Битрикс24 обычно нужно передать не всю карточку задачи, а набор данных, по которым вторая сторона сможет продолжить работу: предмет задачи, срок, приоритет, план, трудозатраты и рабочие отметки. Полная копия карточки создаёт неверные ожидания: на порталах разные сотрудники, права доступа, пользовательские поля и правила работы с проектами.

В актуальном интерфейсе Битрикс24 группы, коллабы и проекты объединены в формат «Проекты AI»; для внешних участников используется проект с гостями. Существующие экстранет-группы продолжают работать, но новые создавать нельзя. Проект с гостями относится к одному порталу, а приложение «Межпортальные задачи и коллабы» связывает задачи между двумя самостоятельными порталами. Обмен работает с задержкой и находится в бета-версии, поэтому настройку лучше строить вокруг конкретных рабочих данных, а не вокруг идентичных карточек.

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

Стандартные поля задач Битрикс24, которые передаются между порталами

Какие поля задачи передавать между порталами Битрикс24 — схема взаимодействия
Какие поля задачи передавать между порталами Битрикс24 — схема взаимодействия

Для связанных задач поддерживается передача таких стандартных полей:

  • название;
  • описание;
  • крайний срок;
  • плановая дата начала;
  • плановая дата окончания;
  • приоритет;
  • теги;
  • оценка времени.

Состояние задачи обрабатывается отдельно. Поэтому список передаваемых полей и правила работы со статусами лучше зафиксировать раздельно.

Название и описание дают исполнителю на втором портале рабочий контекст. В названии удобно указывать предмет работы и ожидаемый результат. В описании — входные данные, критерии приёмки, ссылки на согласованные материалы и ограничения. Если текст редактируют с обеих сторон, командам нужно заранее договориться, на каком портале ведут основную редакцию.

Крайний срок подходит для обязательств перед второй стороной. Плановые даты нужны для календарного планирования: они показывают предполагаемый период работы, но не заменяют крайний срок. Если на одном портале плановые даты не используют, передавать их только ради заполненной карточки не стоит.

Приоритет передаёт отметку срочности. Он не заменяет правила эскалации, согласование переноса срока и распределение исполнителей. Теги лучше оставить для коротких классификаторов: направления работ, тип обращения или этап передачи. Набор тегов стоит согласовать заранее, иначе на порталах быстро появятся похожие по смыслу, но разные метки.

Оценка времени нужна, когда обе стороны используют её для планирования. Если подрядчик ведёт оценку в часах, а заказчик не работает с этим полем, его можно не включать в правила обмена. Переданное значение не делает подходы к учёту трудозатрат общими.

Как передаются название и описание задачи между порталами Битрикс24

Типовой сценарий: менеджер на портале клиента создаёт задачу «Подготовить макет страницы каталога». В описании указывает ссылку на материалы, перечень блоков и дату согласования. После обработки изменения и при доступности обеих сторон на портале подрядчика создаётся связанная задача с переданными названием и описанием. Дизайнер работает в своей карточке и не получает доступ ко всем задачам клиента.

Если клиент убирает из описания устаревшую ссылку, это тоже изменение, которое может дойти до связанной задачи в разрешённом направлении. Временные комментарии, не предназначенные для второй стороны, лучше не оставлять в описании. Для обсуждения подходит чат связанной задачи, но туда передаются только новые пользовательские сообщения, созданные после включения обмена. Старая переписка не переносится.

Как передавать сроки, приоритет и оценку времени в задачах Битрикс24

Условная ситуация: на стороне заказчика задача получила крайний срок 20 сентября и высокий приоритет. Если для передачи этих полей разрешено направление клиент → партнёр, подрядчик после обработки изменения может увидеть значения в зеркальной задаче и использовать их при планировании загрузки команды.

В другом процессе проектный менеджер ставит плановое начало на понедельник, плановое окончание на пятницу и оценку времени. Исполнитель на втором портале получает ориентир для планирования, но эти значения не становятся подтверждённым графиком сами по себе. Если стороны почти одновременно меняют календарь или сроки в двух карточках, более поздно обработанное изменение может заменить другое. Строгий порядок при неоднозначных моментах изменения не гарантируется.

Очистка значений в связанных задачах Битрикс24

Передача поля нужна не только для заполнения. Очистка поддерживаемого значения тоже считается изменением. Если пользователь очистил поддерживаемое поле в исходной задаче, это считается изменением и может привести к очистке соответствующего значения в связанной задаче после обработки изменения и при доступности нужного направления.

После обработки изменения связанная задача может перестать содержать прежнее значение; результат зависит от настроенного направления и доступных прав. Команде нужно учитывать одно правило: не очищать поле «на время», если значение должно сохраниться на втором портале.

Типовой сценарий: заказчик перенёс работу на другой период и убрал прежние плановые даты. Если поле передаётся, старые даты могут исчезнуть и в задаче подрядчика. Когда подрядчику нужен собственный внутренний план, его лучше вести в отдельном поле, которое не сопоставлено с полем клиента.

Очистку нужно тестировать отдельно от заполнения. Проверка, в которой поле только добавили, не показывает, что произойдёт со связанной задачей после удаления значения.

Пользовательские поля задач: как настроить соответствия между порталами

На двух порталах набор пользовательских полей редко совпадает. У клиента могут быть поля «Тип запроса» и «Согласующий», у подрядчика — «Направление работ» и «Ответственный за оценку». Одинаковое название не доказывает одинаковое назначение, а похожий смысл не гарантирует совместимость.

В приложении можно вручную настроить соответствия пользовательских полей двух порталов. Пары не подбираются автоматически по названию, коду, типу или смыслу. Администратор выбирает, какое поле исходной задачи соответствует полю в зеркале, затем проверяет результат тестовой задачей.

Перед настройкой удобно составить короткую таблицу соответствий:

Поле на портале клиента Поле на портале подрядчика Что передаётся
Тип запроса Категория работ Классификация обращения
Номер договора Основание работ Реквизит для исполнителя
Контакт для согласования Контакт проекта Данные для рабочего взаимодействия

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

Правило соответствия пользовательских полей задач Битрикс24

Каждое соответствие должно отвечать на понятный вопрос: какое значение увидит сотрудник на другом портале и что он сможет с ним сделать. Если поле «Тип запроса» у заказчика содержит значения «доработка», «ошибка», «консультация», а поле подрядчика используют для внутреннего учёта по отделам, это плохая пара. Оба поля могут быть списками, но смысл у них разный.

Условная ситуация: заказчик передаёт поле «Контур работ» со значениями «сайт», «CRM», «интеграция». Подрядчик создаёт поле «Направление» с теми же рабочими значениями и вручную связывает поля. После теста можно проверить, получает ли сотрудник ожидаемую классификацию и не приходится ли выбирать её повторно.

Ещё один типовой сценарий: клиент хочет передавать поле «Договор», а на портале подрядчика такого поля нет. Сначала на принимающей стороне нужно создать подходящее поле и определить допустимый формат. После этого можно настраивать соответствие. Значение не появится в произвольном поле карточки без явной настройки.

Несовместимые типы пользовательских полей в задачах Битрикс24

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

Например, поле-список на одном портале может содержать пять статусов, а на втором — три других. Значение «Срочно» не должно автоматически превращаться в произвольный вариант на стороне получателя. Сначала нужно привести оба поля к совместимой рабочей модели либо исключить это соответствие.

Типовой сценарий: у клиента поле «Регион» — список городов, а у подрядчика «Регион» — текстовое поле для внутренней территории. Названия совпали, но содержание разное. Такое соответствие лучше не создавать либо стоит завести отдельное поле с согласованным форматом.

Отдельная проверка нужна для полей, значения которых зависят от прав доступа. Нужно проверить, может ли приложение и участники процесса получить и записать нужные значения на обоих порталах; при недостаточных правах перенос может не состояться.

Как проверить передачу полей тестовой задачей в Битрикс24

Тестовая задача должна повторять обычный рабочий сценарий, а не состоять из одного названия. Её лучше создать в разрешённой области обмена: в выбранном проекте, рабочей группе, существующей коллабе или по ответственному, если настроен обмен по ответственным.

Проверка может состоять из пяти действий:

  1. Создать тестовую задачу с названием, описанием, сроком, плановыми датами, приоритетом, тегами и оценкой времени.
  2. Заполнить каждое настроенное пользовательское поле допустимыми значениями.
  3. Дождаться связанной задачи на втором портале и сверить каждое поле с таблицей соответствий.
  4. Изменить часть значений, затем очистить срок, тег или другое поддерживаемое поле и проверить результат в зеркале.
  5. Проверить обратное направление только для тех полей, для которых оно разрешено.

Условный пример: клиент создаёт задачу в проекте с заполненным полем «Тип запроса». Подрядчик получает зеркало, меняет описание и убирает один тег. Затем клиент проверяет, какие изменения пришли обратно согласно отдельным разрешениям. Так команда проверяет передачу полей при создании и поведение задачи при дальнейших правках.

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

Частые вопросы о передаче полей задач между порталами Битрикс24

Передаются ли все поля карточки задачи Битрикс24?

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

Можно ли автоматически сопоставить пользовательские поля по названию?

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

Передаётся ли удаление значения из поля задачи?

Очистка поддерживаемого значения считается изменением. Она может привести к очистке соответствующего значения в связанной задаче после обработки изменения, если это разрешено настроенным направлением и доступны нужные права.

Что делать, если пользовательские поля имеют разные типы?

Не связывать их до проверки совместимости. Иногда достаточно создать на принимающем портале поле с подходящим типом и согласованными значениями. В других случаях поле лучше оставить внутренним.

Можно ли передавать поля только от клиента подрядчику?

Да. После сохранения сопоставления начинает работать направление клиент → партнёр. Обратные изменения настраиваются отдельными разрешениями, поэтому двусторонний обмен не включается автоматически.

Нужно ли проверять права доступа при передаче полей?

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

Вывод: какие поля стоит передавать

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