Searching the Help
To search for information in the Help, type a word or phrase in the Search box. When you enter a group of words, OR is inferred. You can use Boolean operators to refine your search.
Results returned are case insensitive. However, results ranking takes case into account and assigns higher scores to case matches. Therefore, a search for "cats" followed by a search for "Cats" would return the same number of Help topics, but the order in which the topics are listed would be different.
Search for | Example | Results |
---|---|---|
A single word | cat
|
Topics that contain the word "cat". You will also find its grammatical variations, such as "cats". |
A phrase. You can specify that the search results contain a specific phrase. |
"cat food" (quotation marks) |
Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase. |
Search for | Operator | Example |
---|---|---|
Two or more words in the same topic |
|
|
Either word in a topic |
|
|
Topics that do not contain a specific word or phrase |
|
|
Topics that contain one string and do not contain another | ^ (caret) |
cat ^ mouse
|
A combination of search types | ( ) parentheses |
|
Mandatory manual migration tasks
Note Some manual migration tasks are only mandatory under certain conditions. See each task for further information.
Review the migrated validity records
After you migrate to Service Manager Hybrid, validity records are validated against the Process Designer category tables instead of the Classic category tables. Therefore, a manual review of the validity records is required.
A Process Designer migration report that resembles the following is included in the pdmigration.log file:
The following validity records are updated to perform validation against Process Designer-based category tables (such as category, subcategory, and producttype) instead of legacy category tables. Backups of the original validity records (identified by the suffix "_disabled") have been created.
Unique ID:BP;Field Name:category;Sequence:1
Unique ID:BP;Field Name:category;Sequence:3
Unique ID:BP;Field Name:incident.category;Sequence:3
Unique ID:BP;Field Name:product.type;Sequence:1
Unique ID:BP;Field Name:product.type;Sequence:2
Unique ID:BP;Field Name:product.type;Sequence:3
Unique ID:BP;Field Name:product.type;Sequence:5
Unique ID:BP;Field Name:product.type;Sequence:7
Unique ID:BP;Field Name:product.type;Sequence:10
Unique ID:BP;Field Name:product.type;Sequence:13
Unique ID:BP;Field Name:subcategory;Sequence:1
Unique ID:BP;Field Name:subcategory;Sequence:2
Unique ID:BP;Field Name:subcategory;Sequence:3
Unique ID:BP;Field Name:subcategory;Sequence:5
Unique ID:BP;Field Name:subcategory;Sequence:11
Unique ID:BP;Field Name:subcategory;Sequence:12
The number of updated validity records depends on your system configuration. If you have not customized any validity records, you can ignore this step.
Note If you have added dbdict fields to the category tables and if you use the validity table to validate against these fields, you must manually change the validation logic for these fields.
Review the category-based alerts migration
Stage 1, 2, and 3 alerts and deadline alerts
The Applications Upgrade Utility migrates the Classic Stage 1, Stage 2, Stage 3, and Deadline alerts and Deadline Alert Group configurations from Classic categories to the workflow phases of the automatically-generated Incident workflow.
The migrated alerts are named according to their source. For example, "Incident Alert Stage 1 for complaint" indicates that the alert is converted from stage 1 configuration of the complaint category. The following types of alert are created:
- Incident alert stage 1 for <category name>. This alert updates the incident alert status to "alert stage 1" if the category has a stage 1 interval or expression specified.
- Incident alert stage 2 for <category name>. This alert updates the incident alert status to "alert stage 2."
- Incident alert stage 3 for <category name>. This alert updates incident alert status to "alert stage 3."
- Incident Deadline for <category name>. This alert updates the incident alert status to "DEADLINE ALERT."
The migrated alerts are located in the alerts tab of each workflow phase.
Gap and limitations
The migrated alerts implement the main functionality of the Classic alerts; however, there are some gaps and limitations.
- In Classic category-based alert expressions, "$file" represents the incident. The Applications Upgrade Utility automatically modifies "$file" to "$L.file" for compatibility with the migrated alerts. If you use other variables in your Classic system, you must manually modify the expression in the migrated alerts.
-
The timing for the generation of stage 2 and 3 alerts is different. In the Classic Incident module, the schedule for stage 2 is generated after the schedule for stage 1 is executed and the incident alert status is updated to stage 1. Likewise, the schedule for stage 3 is generated after the schedule for stage 2 is executed and the incident alert status is updated to stage 2. In Hybrid mode, however, all schedule records for stage 1, stage 2, stage 3, and deadline alerts are generated or re-generated at the same time, when the incident record is updated.
Therefore, if you are using an expression that uses the content of the current record ($file) as either the condition or the calculation for the alert time in stage 2, stage 3, or deadline alerts, issues may occur because the content of the current record can differ when the schedule is generated.
-
The migrated alerts are moved to the alerts list of the "In Progress" phase of the migrated Incident workflow. If you add new phases, you need to also add these alerts to new phases so that the alerts can work for incident in the new phases.
-
The alert reset and recalculation conditions in objects are changed in Hybrid mode. Therefore your original alerts may not work. For example, the out-of-box alert reset condition in the Classic probsummary object is
category in $L.file="incident" and not (null(1 in external.process.reference in $L.file))
. If you use this condition, alerts only work for incidents that are assigned to the incident category. In the migrated probsummary object, the condition isevaluate(nullsub(parse(str(alertsReset in $L.wfPhase), 2), false)) or not (same(current.phase in $L.file, current.phase in $L.file.save))
, and the alert reset condition of the "In Progress" phase is set to "true." Therefore, all alerts configured in the phase will work for all incidents rather than only for incidents that are assigned to the incident category.In this case, you can modify the schedule condition and the alert condition in the existing alert definition of the Incident Management module by appending the original reset condition that is configured in the Classic object.
Reassignment threshold
The reassignment interval and expression and the reassignment count threshold in the Classic categories are not migrated automatically.
If you still need reassignment threshold functionality, you can add the relevant fields to the new Process Designer-based category file and form, and then copy the configuration to the new Process Designer categories. The following table lists the fields that you will need to add.
Field name in dbdict |
Data type |
Label in form/description |
---|---|---|
count |
number |
Reassign Count Threshold |
reassign |
date/time |
Reassignment Interval |
reass.expression |
expression |
Reassignment Expression |
Review Change Management processes
Note The following step applies only to customers who upgrade to Service Manager Hybrid from a system that does not have PDCP3 installed.
Renamed processes
The following two Classic processes in DocEngine are renamed by the Applications Upgrade Utility. The old Classic names are now used for Codeless processes.
Process name in Classic mode | Process name in Hybrid mode |
---|---|
cm.open |
cm.open.classic |
cm.open.save | cm.open.save.classic |
Therefore, if you have made any customizations to the processes, a conflict with the new name will be reported in the upgrade results (for example, if you customized “cm.open”, this process will be renamed to “cm.open.classic” and will conflict with the out-of-box “cm.open.classic”.) Additionally, if you have made any customizations that call the Classic processes, you must update these to call the new process names.
Review "Close Phase"
In the migrated Change Management workflow, the "Close Phase" functionality is moved to transitions between phases. In Classic versions of Service Manager, the "close" display option closes intermediate phases and closes the change or change task in the last phase. In the migrated Change Management workflow, the "close" display option closes only changes or change tasks in the last phase in the workflow.
The following condition is added to the original condition of the "cm.view.display_close" display option:
($G.pd.change.enabled=false or index(current.phase in $L.file, phases in $L.category)=lng(denull(phases in $L.category)) or category in $L.file="Unplanned Change" and current.phase in $L.file="Discovery Assessment") and
If you have tailored this display option, or if you have configured other display options to perform the "close" action, you must make equivalent modifications to ensure that the close action only works for last phase.
In Hybrid versions of Service Manager, display options are not called during the "close" phase. Therefore, the "cm.view.display_close" display option code is migrated to the "cm.save.wrapper" process, as illustrated by the following image. If you have tailored this display option, you must make equivalent changes to the process.
In out-of-box Hybrid versions of Service Manager, the transition between phases is named "Close Phase". However, you can modify the label to suit your needs by using the localization functionality in the Workflow Editor.
Modify $L.env to $G .cm3r.environment/$G.cm3t.environment
In the Classic Change module, $L.env is a "cm3profile" record, whereas in Hybrid Change it is a "tableAccess" record. Therefore, references to $L.env are updated to refer to $G.cm3r.environment/$G.cm3t.environment, in case a "cm3profile" record is required (the $G.cm3r.environment/$G.cm3t.environment global environment variable contains the same content as the Classic version of the $L.env record).
In out-of-box Hybrid versions of Service Manager, all the related display screens, display options, and processes in the Change Management module are updated. For example, in "cm.view.display_reopen", evaluate(reopen in $L.env)
is updated to (filename($L.file)="cm3r" and evaluate(reopen in $G.cm3r.environment) or filename($L.file)="cm3t" and evaluate(reopen in $G.cm3t.environment))
.
However, you must make equivalent updates for any tailoring you have made that uses $L.env as a "cm3rprofile" record.
Revert to status-based SLM for Change Tasks
Note The following step applies only to customers who upgrade to Service Manager Hybrid from a system that does not have PDCP3 installed.
Service Level Management (SLM) for Change Tasks in Codeless versions of Service Manager is based on phases, whereas in Classic versions it is based on statuses. Therefore, you must revert to status-based SLM for Change Tasks in order for your existing SLAs to work with the migrated workflows.
To do this, follow these steps:
- In the System Navigator, click Service Level Management > Administration > Configure Application.
- In the Table Name drop-down list, select cm3t.
- In the Process Target Information section, click to clear the Use Phases option, and then configure the Process Target State Progression and Standard Alerts fields as required.
Review the "form edit" condition in workflow phases
The “form edit” condition in Process Designer-based workflows determines whether a form is editable when a user views a record. In Service Manager Classic, this control condition may be located different places. When the Applications Upgrade Utility creates the migrated workflows for Hybrid mode, the condition settings are migrated from the default location of the condition in Service Manager Classic:
- Service Desk: The condition is copied from the state input condition
- Change: The condition is copied from the legacy change phase
If you have configured the condition in any other location, it will not be automatically migrated. In this situation, you must manually combine the Classic condition settings into the “form edit” condition.
Note Whilst we recommend that you use the “form edit” condition in workflow phases in Service Manager Hybrid and Codeless, the “IO control” condition for the display screen still works. If you set both conditions, the form is editable only when both condition are met.
Merge the status lists
The Applications Upgrade Utility implements the Process Designer search form and the Process Designer status list. Therefore, you must merge the Classic status list into the Process Designer-based status list.
The following table describes the table in each module that you must update, along with information about the Globallist, the Globalvariables, and where the data comes from.
We recommend that you modify the data in the ModuleStatus database according to your needs. For example, you must update the ModuleStatus list for the Incident module to add or remove statuses according to your requirements.
Module |
Global list name |
Process Designer statuses global list variable |
Details |
---|---|---|---|
Incident |
Incident Local Statuses |
$G.imStatuses |
Retrieve from file ModuleStatus with Limiting SQL module="probsummary" |
Service Desk |
Interaction Local Statuses |
$G.sdStatuses |
Retrieve from file ModuleStatus with Limiting SQL module="incidents" |
Problem |
Problem Local Statuses |
$G.pbmStatuses |
Retrieve from file ModuleStatus with Limiting SQL module=" rootcause" |
Problem |
Problem Task Local Statuses |
$G.pbmTaskStatuses |
Retrieve from file ModuleStatus with Limiting SQL module=" rootcausetask" |
Note Both the Process Designer-based and Classic Change modules use the same status list.
Update the eventin service
If you use the eventin service to create Incidents, and if the RAD applications of your Event Register for creating the Incidents is set to "axces.apm," you must check whether the "add" action in the document engine's state records action blocks externally-created Incidents.
To do this, first identify which process maps to the "add" action in the Classic Open State. The following illustration uses the im.first process as an example from an out-of-box system.
In out-of-box systems earlier than Service Manager 9.41, only the "problem" and "EXTERNAL" operators have permission to add Incident records from the backend.
Make sure that the User IDs of your eventin services are configured as demonstrated in the following image.
Alternatively, make sure the User IDs of your eventin services are not blocked. To do this, you can change your code to allow all backend operations, as illustrated by the following image.
If you use the following applications in your event register, the relevant eventin services are now allowed to trigger the Process Designer rule sets.
RAD applications |
File |
Out-of-box event registers |
---|---|---|
axces.apm |
probsummary |
pmu: problem update pmr: problem reopen pmo: problem open pmm: problem mibile checkout/in pmc: problem close ... (total 19 eventregisters) |
axces.apm.epmosmu |
probsummary |
epmosmu: e problem open smu |
axces.sm |
incidents |
esmin: e service management smin: service management |
axces.cm3 |
cm3r cm3t |
cm3rin cm3tin ... (total 14 eventregisters) |
Note
- The Change module eventin services (such as eventregister cm3rin and cm3tin) can already trigger Process Designer rule sets.
- If you use the axces.database RAD applications (the behavior of which is not changed by the Process Designer migration) as the eventregister application, the eventin services will not trigger the Process Designer rule sets.
Replace the environmental variables
In Service Manager Classic, the $L.env
variable stores the profile record. However, in Service Manager Codeless, the $L.env
variable stores the tableAccess record. Therefore, all code in the Change Management module that uses the $L.env
variable (mostly, this relates to Display Options) must be updated to use the $G.cm3r.environment
or $G.cm3t.environment
variables.
For example, the display condition of the cm.view.display_approve display option must be updated as follows:
Original:
evaluate(approvals in $L.env)
After update:
evaluate(approvals in $G.cm3r.environment) or evaluate(approvals in $G.cm3t.environment)