Ограничения

Руководство описывает ограничения во время и после миграции и, где возможно, способы их обхода. Оно разделено на 3 основных раздела:

• Ограничения миграции данных модулей
• Ограничения миграции административных данных
• Предельное число символов и сущностей в облачной версии

---

 

Ограничения миграции данных модулей

Все модули

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

 

Связи заявок с изменениями не переносятся.

 

Число добавляемых вложений не ограничено, но общий размер всех вложений одной сущности не должен превышать 48 МБ. Вложения больше 48 МБ не переносятся.

 

При миграции данных модулей сведения вкладки истории не переносятся.

 

Если за знаком меньше (<) следует !, -, \ или буквы, этот знак удаляется при миграции, кроме полей с форматированным текстом.

Например, text< переносится как text<, а text<1 переносится как text<1.

Однако text<a переносится как texta, а text<! переносится как text!

 

Для дополнительных полей типа списка, флажка, переключателя и множественного выбора:

• Специальные символы ` ~ # % ^ & * ( ) = + ? [ ] { } | ; " " удаляются из вариантов при миграции, поскольку не поддерживаются в облачной версии.
• Если вариант содержит только указанные специальные символы, дополнительное поле не переносится.
• Если вариант поля пуст, добавляется фиктивная запись.

 

В сущностях, кроме инцидентов, услуг, активов и рабочих станций, пользовательские поля типов radio, checkbox и decimal переносятся как picklist, multi-select и single line соответственно.

 

Если значение дополнительного поля по умолчанию превышает предел числа символов, поле не переносится.

 

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

 

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

 

Предельные значения полей задач и шаблонов услуг в облачной версии приведены ниже:

Модуль	Название поля	Максимальное значение
Задачи: общие, заявок, изменений, проектов, проблем и контрольных этапов	additional_cost	9999999999999999
	estimated_effort_days	9999
	estimated_effort_hours	999
	estimated_effort_minutes	999
Шаблоны услуг	Стоимость услуги (Service Cost)	1000000000000000
	Стоимость варианта ответа (Question Option Cost)	1000000000000000

 

Главная

В делегированиях, например резервного согласующего, переносятся только будущие делегирования.

Задачи: общие, заявок, изменений, проектов и проблем

Шаблоны задач, не связанные с заявками или проектами, не переносятся.

 

Циклические задачи и шаблоны задач не переносятся и вызывают следующую ошибку: Нельзя добавить выбранную зависимость: прямая или косвенная зависимость между исходным и целевым узлами уже существует (Cannot add the selected dependency as either a direct or an indirect dependency already exists between the source and the target node)..

 

Поле Уведомить до запланированного начала (Notify before scheduled start) локальной версии переименовывается в Отправить мне письмо до запланированного начала (E-mail me Before Schedule Start) в облачной версии.

 

После миграции напоминание о задаче однократно отправляется её специалисту согласно настройке поля Письмо заранее (Email Before) .

Заявки

Зависимости заявок и вложения примечаний не переносятся из-за отсутствия этих возможностей в облачной версии.

Начиная со сборки 14202 системные уведомления заявок по умолчанию не переносятся.

Заявки с запланированным началом или окончанием ранее времени создания не переносятся.

 

Связи между связанными заявками не переносятся.

 

Заявки в корзине не переносятся.

 

Согласования, зависимости и ресурсы архивных заявок не переносятся.

 

Вложения, отсутствующие по указанному пути вложений, не переносятся.

 

Решения длиннее 65536 символов обрезаются до 65536 символов.

Переносятся только первые 100 адресов электронной почты в заявках и первые 50 в уведомлениях. Остальные обрезаются при миграции.

 

Связи SLA переносятся, если они настроены вручную в облачной версии. Однако после миграции письма эскалации не отправляются и действия SLA не выполняются.

 

После переноса согласований невозможно одобрить, отклонить или отправить уведомление, если согласующий был несистемным пользователем локальной версии.

 

Пустые этапы согласования пропускаются. Последующие этапы переносятся с исходным идентификатором уровня.
Например, если этап 2 не содержит согласований, он не переносится, а этап 3 переносится как этап 3, но в интерфейсе показывается как этап 2..

 

В отменённых заявках задачи, не имеющие завершённого статуса — closed, canceled, resolved или пользовательского завершённого — переводятся в статус Отменена (Canceled) при миграции.

 

Проверка связи «площадка — группа — специалист» пропускается при миграции.
Например, если специалист удалён с площадки или из группы, их заявки остаются в области доступа специалиста, пока сведения не будут обновлены вручную.

 

Заявки удалённых отделов перемещаются в отдел заявителя.

 

Форматированный текст описания трудозатрат переносится как обычный текст с потерей оформления.

 

Если специалист, запланировавший приостановленную заявку (On Hold), удалён из приложения, заявка назначается специалисту, запустившему миграцию.

 

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

 

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

 

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

Изменения

После миграции последовательность идентификаторов изменений приводится к существующей последовательности облачного экземпляра.

 

Правила закрытия изменений, связанные с вложениями, не переносятся.

Связь пользователя с ролью изменения не переносится для типа роли «Группы поддержки» (Support Groups), поскольку эта возможность отсутствует в облачной версии.

 

Члены CAB без права входа не переносятся. Если право входа отсутствует у всех членов CAB, сам CAB также не переносится.

 

При миграции изменений на этапе Submission пользователи удаляются из соответствующих полей при выполнении любого условия ниже. На остальных этапах пользователь сохраняется.

• Пользователь роли изменения перенесён как заявитель либо удалён из роли или организации.
• Пользователь роли SDChangeManager перенесён как заявитель либо удалён из роли или организации.
• Пользователь роли, предназначенной для специалистов, перенесён как заявитель либо удалён из роли или организации.

 

Если уровень согласования имеет статус Ожидает согласования (Pending Approval) , а согласующий не имеет права входа, при миграции согласование переводится в статус Ожидает отправки (To Be Sent) .

 

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

 

Изменения со статусом, отличным от Approved/Denied, после миграции отображаются с пустым статусом.

 

Для изменения переносится не более 300 задач.

Проекты

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

Модуль	Название поля	Максимальное значение
Проекты	estimated_hours	99999
	actual_hours	99999
	estimated_cost	999999999999
	actual_cost	999999999999
Проекты (Projects) >> Контрольные этапы (Milestones)	estimated_hours	99999
	actual_hours	99999

 

Решения

Поле владельца решения (Solution Owner) и тип обходного решения (Workaround) не переносятся из-за отсутствия этих возможностей в облачной версии.

 

Поскольку поле Описание (Description) обязательно для решений в обеих версиях, при миграции пустые описания заполняются фиктивной записью.

 

Если дата проверки (Review Date) совпадает с датой истечения (Expiry Date) или позже неё, решение не переносится.

Активы

Рабочие станции, виртуальные машины и виртуальные узлы с одинаковыми сервисными метками нельзя перенести напрямую. Однако эти метки можно добавить в Setup > Probes and Discovery > General > Invalid Service Tags и выполнить миграцию, чтобы перенести все компьютеры из локальной версии (OP).

Виртуальные машины без виртуальных узлов не переносятся, поскольку Virtual Hosts обязательны в ServiceDesk Plus Cloud.

Активы в состоянии Используется (In Use) переносятся как На складе (In Store) , если связанный пользователь уволен и актив не связан с отделом, либо связанный отдел больше не используется и актив не связан с пользователем.

Модуль активов определённого типа экземпляра локальной версии переносится только в такой же тип экземпляра облачной версии.

При нарушении любого условия ниже соответствующее поле даты актива устанавливается в null:

• Дата истечения должна быть позже даты приобретения.
• Дата окончания гарантии должна быть позже даты приобретения.
• Дата окончания гарантии должна быть раньше даты истечения.

Техническое обслуживание

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

 

Расписания обслуживания не переносятся. После миграции пользователи могут настроить их вручную.

Отчёты

Отчёты по запросам не переносятся.

 

Заказы на закупку

В заказах на закупку переносятся только 5 этапов согласования: в облачной версии максимум составляет 5 уровней. Остальные переносятся и показываются как поля только для чтения.
Значение места (place) в заказе — стандартное; его нельзя добавить через API закупок локальной версии, поэтому поле place не переносится.

 

 

Договоры

Продление договора в облачной версии должно иметь уникальное название. Договоры с повторяющимися названиями не переносятся.

Срок дочернего договора должен находиться в пределах срока родительского. Истёкший родительский договор не может иметь дочерних договоров.

Данные дочерней сущности продлений переносятся из OP, но история продлений не отображается в списке Contract Renewals.

При миграции родительский и дочерний договоры должны иметь одного поставщика.

Числовое дополнительное поле содержит не более 15 цифр; превышение вызывает ошибку.

 

Проблемы

Следующие данные проблем не переносятся:

• Административные сущности проблем: дополнительные поля, пользовательские триггеры, правила уведомлений и закрытия, шаблоны проблем и пользовательские функции проблем

• Решения и обходные решения проблем

• Уведомления проблем

• Связи проблем

Форматированный текст описания трудозатрат переносится как обычный текст с потерей оформления.

 

Ограничения миграции административных данных

Каталог ESM (ESM Directory)

Роли организации переносятся, но сопоставление пользователей с ними пока не поддерживается.

 

В поле согласующих (Approvers) согласований шаблонов, задач PM и правил полей и форм роли организации, кроме COO, CEO, CFO и CIO, переносятся в эквивалентные роли заявки облачной версии.

Пример:

• Ответственный/руководитель площадки (Site Incharge/Manager) переносится как ответственный/руководитель площадки заявителя (Site Incharge/Manager of Requester)
• Ответственный/руководитель региона (Regional Incharge/Manager) переносится как ответственный/руководитель региона заявителя (Regional Incharge/Manager of Requester)

 

Пользователи

Изображения профилей пользователей не переносятся.

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

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

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

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

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

Группы поддержки

1. Название группы поддержки не должно превышать 50 символов.

2. Активная группа поддержки переносится как неактивная, если в ней не настроены специалисты.

3. Адрес электронной почты и имя отправителя группы поддержки должны соответствовать регулярному выражению.

4. Имя и адрес отправителя группы поддержки не переносятся, если хотя бы одно из этих значений пусто.

Настройка службы поддержки

Поле Менеджер изменений (Change Manager) в категории не переносится из-за отсутствия этой возможности в облачной версии.

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

Численные ограничения контрольных списков приведены ниже. При превышении сущность не переносится.

• 100 контрольных списков
• 500 элементов контрольных списков
• 25 вариантов в элементах типа переключателя
• 250 символов в однострочных элементах контрольных списков

 

Переносятся только элементы, связанные с контрольным списком.

 

Для одного контрольного списка переносится не более 25 элементов.

 

В заявках и шаблонах заявок переносится не более 25 связанных контрольных списков.

 

Если с заявкой связан контрольный список с удалённым элементом, при миграции заявки этот элемент создаётся в удалённом состоянии в разделе Настройка (Setup) > Настройка интерфейса (Customization) > Контрольные списки (Checklists) > Элемент контрольного списка (Checklist Item) и сопоставляется с заявкой.

Пользователь, запустивший миграцию, добавляется в поле Создано пользователем (Created by) контрольных списков заявок и архивных заявок.

Если сведения о создавшем или обновившем список пользователе локальной версии не переносятся, пользователь, запустивший миграцию, добавляется в поля Создано пользователем (Created by) и Обновлено пользователем (Updated by) .

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

Управление инцидентами и услугами

Ограничения дополнительных полей заявок

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

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

 

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

 

Дополнительные поля заявок типа radio не шифруются в облачной версии.

 

Ограничения шаблонов

Следующие данные не переносятся из-за отсутствия возможностей в облачной версии:

• Цвет и шрифт форм шаблонов инцидентов и услуг
• Справочный текст разделов и полей шаблонов инцидентов и услуг
• Значки шаблонов инцидентов и услуг
• Краткое описание, инструкции, примечания и рекомендации для специалистов и заявителей в шаблонах инцидентов и услуг
• Действия шаблонов услуг

 

С шаблоном инцидента или услуги можно связать не более 200 задач.

 

$EmailSignature и $ITService не подставляются в шаблонах ответов из-за отсутствия соответствующих возможностей в облачной версии.

 

От имени (On Behalf Of) добавляется во все шаблоны заявок при миграции, если возможность включена в локальной версии.

 

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

 

Поля Запланированное начало (Schedule Start Time) и Запланированное окончание (Schedule End Time) добавляются в компоновку специалиста облачного шаблона при миграции.

 

Связи шаблонов с SLA не переносятся.

 

Варианты программного обеспечения в вопросах о ресурсах не переносятся.

 

В облачной версии нет поддержки PII — информации, позволяющей установить личность — для вопросов с флажками.

 

Вопросы типа раскрывающегося списка и переключателя переносятся как вопросы с полем выбора и поддержкой PII.

 

Численные ограничения ресурсов шаблонов услуг:

• 20 ресурсов на шаблон. Превышение вызывает ошибку 4018 .
• 20 вопросов на ресурс. Превышение вызывает ошибку 4018 .
• 300 вариантов на вопрос. Превышение вызывает ошибку ARRAY_SIZE_OUT_OF_RANGE .

 

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

 

При переносе данных из локальной Standard Edition в облачную Standard Edition полеКатегория услуги (Service Category) шаблонов инцидентов и административная сущность Категория услуги (Service Category) не переносятся из-за отсутствия возможности в облачной версии.

 

Ограничения правил полей и форм

Названия правил полей и форм в облачной версии общие для всех шаблонов и нечувствительны к регистру. Поэтому локальные правила с названиями, различающимися только регистром, считаются дубликатами. Второе правило не переносится и вызывает ошибку 4008.

 

В разделах событий, условий и действий действуют следующие ограничения:

Раздел правил полей и форм	Ограничение
Событие	При событии «Изменение поля» (On Field Change) правило не переносится в следующих случаях: Настроено полеСогласующие услуги (Service Approvers) . Настроено поле Причина (Reason) и выполнение правила задано для операций 'On Create/Edit' или 'On Create'.
Условия	Ожидает отправки (To Be Sent) не поддерживается как критерий статуса согласования (Approval Status). Критерий с полями Logged-in User Details/User details (username, email id, department), Site, Group или On Behalf Of вызывает ошибку: в локальной версии это текстовые поля, а в облачной — поля поиска. is_empty и is_not_empty для полей даты и времени не переносятся.
Действия	Действия правил полей и форм переносятся, кроме пользовательских сценариев. Если правило содержит только сценарии, возникает ошибка No Valid actions found («Допустимые действия не найдены») . Действия полей Enable Fields, Disable Fields, Hide Fields, Show Fields, Mandate Fields, Non-Mandate Fields и Clear Fields не поддерживаются в облачной версии для полей Активы (Assets), Заявитель (Requester)и От имени (On Behalf Of) . Действие Set Field не поддерживается в облачной версии для полей Срок выполнения (DueBy Date), Группа (Group)и Площадка (Site) . Действия Mandate Fields и Non-Mandate Fields недоступны для поля Площадка (Site) . Правило полей и форм НЕ переносится, если: Действие настроено для поля Согласующие услуги (Service Approvers) и выполнение правила задано для операций Приизменении (On Edit). Действие настроено для поля Причина (Reason) и выполнение правила задано для операции При создании (On Create) .

 

 

Управление изменениями

$AllTechnicians в шаблонах изменений не переносится из-за отсутствия соответствующей роли в облачной версии.

Правила полей и форм изменений не переносятся.

Число членов CAB ограничено 100.

Поле Получатели (Notify to) статуса изменения ограничено 200 ролями.

С ролями изменения в шаблоне можно связать не более 1000 пользователей.

В reason_for_change название предварительно заполненной записи Обновления вследствие технологических изменений (Upgrades based on technology changes)различается, поэтому создаётся новая запись.

После миграции роли изменения получают право просмотра всех этапов.

Поля Stage и Status шаблонов изменений устанавливаются в Submission и Requested соответственно.

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

Управление активами

Стандартные типы продуктов с изменёнными названиями переносятся с исходным стандартным названием.
Например, если стандартный тип workstation переименован в workstation1, при миграции ему возвращается стандартное название workstation.

Аналогично пользовательский тип с названием стандартного типа продукта переименовывается в name_id.

Переключатели radio не поддерживаются в дополнительных полях активов.
Управляемое ПО переносится; остальные типы пока не учитываются.

 

URL сайта поставщика в облачной версии должен начинаться с "http" или "https" и иметь допустимый формат. Несоответствие вызывает следующую ошибку: PATTERN_NOT_MATCHED.

Интеграции

Перенесённые данные облачной версии не синхронизируются с Zoho Analytics.

 

Предельное число символов и сущностей в облачной версии

Число символов следующих полей ограничено максимумом облачной версии. Превышающие предел символы обрезаются при миграции:

• Описание трудозатрат задачи обрезается до 3000 символов.
• Комментарий шаблона заявки обрезается до 250 символов.
• Комментарий согласования заявки обрезается до 1000 символов.
• Комментарий флага отмены, планировщика приостановки, Closure comment и Closing comment (комментарий подтверждения заявки) обрезается до 250 символов.
• Описание категории услуги обрезается до 100 символов.
• До 250 символов обрезаются описания административных сущностей изменений: риск, причина, код закрытия, этап и статус, правило закрытия и шаблон изменения.
• Максимальное число сущностей для миграции в облачную версию:

Статус (Status): ["75"]

Приоритет (Priority): ["150"]

Тип задачи (Task Type): ["50"]

Тип трудозатрат (Worklog Type): ["100"]

Категория (Category): ["1000"]

Подкатегория (Subcategory): ["5000"]

Элемент (Item): ["15000"]

Срочность (Urgency): ["75"]

Влияние (Impact): ["75"]

Уровень (Level): ["750"]

Способ обращения (Mode): ["300"]

Код закрытия заявителя (Requester Closure Code): ["100"]

Шаблон ответа (Reply Template): ["300"]

Шаблон решения (Resolution Template): ["300"]

Тип заявки (Request Type): ["2500"]

Подробнее об ограничениях числа полей — здесь.