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