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