- Key Terms
- Introduction
- Preparing to Design Services
- Configuring Categories and Service Items for Services
- Configuring Forms for a Service
- Configuring Services and Service Bundles
- Designing Plan for Delivering Services
- Configuring Rates and Accounts For Billing
- Additional Configurations For Designing Services
- Managing the Services and Attributes
- Designing Portlets and Portals Using Portal Designer
- Localizing Service Catalog
- Use Case of Designing a Service to Select Laptop
- Namespaces
- Form Rule and ISF JavaScripts UseCase Analysis
- Key Terms
- Index
Cisco Prime Service Catalog 12.1 Designer Guide
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
- Updated:
- August 30, 2017
Chapter: Designing Plan for Delivering Services
- Designing Plan for Delivering Services
- Configuring Delivery Tasks
- Defining Service Item Task in a Delivery Plan
- Service Item Subscription Processing Rules
- Service Item Task Operations
- Configuring an External Task
- External Service Item Task Operations
- Defining Directory Tasks in the Workflow
- Configuring AMQP Tasks for Publishing Service Request to an External System
- Creating Service Delivery Tasks for Granting and Revoking Permissions for a Service Item
- Creating a Scheduled Start For a Delivery Task
- Defining Task Participants
- Defining Email Notifications for Delivery Tasks
- Adding Task Instructions
- Creating Checklist For Completing a Task
- Configuring Escalation Email for Delayed Tasks
- Designing Service Delivery Workflows
- Configuring Authorizations
Designing Plan for
Delivering Services
This chapter contains the following topics:
Designing Plan for Delivering Services
A delivery plan comprises one or more tasks that must be completed to deliver a service to a customer. The tab is used to define the delivery plan for a service.
Before You Begin
- Identify what the tasks (or series of tasks) are
- Identify whether the service requires email notifications
- Identify who the performer, supervisor, and email recipients are
Also, have an understanding of the following concepts
- Using Namespace variables and configuring expressions, as detailed in Namespaces.
- Configuring and using email templates, as detailed in the Cisco Prime Service Catalog Administration and Operations Guide . For namespace usage in email templates, see Namespace Usage in an Email Template.
- Calculation of due dates. See Forecasting Due Dates.
Configuring Delivery Tasks
Every delivery plan automatically has one overall task, that allows a designated project manager to monitor the delivery plan’s progress. Using the Tasks subtab you can specify the tasks and detailed activities for each task of the service delivery plan. You define the tasks by listing them in the appropriate order; subtasks and parent tasks are indicated, much the same way as Project Management software shows projects and deliverables within a project.
| Step 1 | Select . |
| Step 2 | Select the
service and choose
Plan >
Tasks. If multiple tasks are listed on the Plan tab, click on the task name
you want to configure.
When the task is highlighted in blue/gray, you are ready to begin; each task you want to configure has its own set of subtabs: General, Participants, Email, Task Instructions, and Checklist. |
| Step 3 | Define the task details. For more information, see Fields in Task Subtab |
| Step 4 | Add tasks. Ideally you should be able to move through the fields described below in order as you create detailed delivery activities.For more information, see Fields in Task Table. |
| Step 5 | Click
General
sub tab and create detailed plan activities for delivery of a task including:
the task name, execution order, duration, priority, and conditions.
If your company’s installation is integrated with third-party software using Service Link, then you also choose the external action here. If you are using Service Item Manager, you can also choose Service Item tasks here. For more information, see Defining Delivery Activities for a Task. |
| Step 6 | Click Participants sub tab and define the details about the performer of the task, including who completes the task and how the work is supervised. |
| Step 7 | Click Email subtab and define the optional email templates that the system sends when the task starts, completes, is cancelled, is rescheduled, is reassigned, or when an external task fails. For more information, see Defining Email Notifications for Delivery Tasks. |
| Step 8 | Click Task Instructions and enter instructions for the task or set links to any task instruction-related URLs. For more information, see Adding Task Instructions. |
| Step 9 | Click Checklist sub tab and create a list of reminders or detail the procedural steps for completing a task. These appear in Service Manager as a checklist, detailing steps for completing the work. For more information, see Creating Checklist For Completing a Task. |
The Fields in Task Subtab table summarizes the fields on the Tasks subtab that pertain to the “Monitor” task, that is, the overall delivery plan. For more information, see Configuring Bundles of Related Services
|
Field |
Description |
|---|---|
|
Project Manager |
Assigns a project manager from a position, a person/queue, or an expression. The project manager is the person, position, or queue that receives the Plan Monitor Task for a service in Service Manager. This task allows to oversee the entire delivery process including making adjustments to staffing, rescheduling and completing tasks, and even cancelling the entire delivery plan, if needed. Clicking on the “...” button on the right pops up a dialog box allowing you to search for and designate a position, a person/queue, or to type in the parameters of your expression. For an expression, click Set Expression to save. |
|
Subject for plan monitoring task |
Text describing the subject of the monitoring task for the plan. It is recommended that you place the word “Monitor” in the subject. The plan subject may include namespaces, as documented in Namespaces. Clicking on the “...” button allows you to edit the subject. Click Set Subject to save changes. |
|
Top level tasks execute |
Indicates whether top-level tasks in the delivery plan execute concurrently (at the same time) or sequentially (in order, one after the next). |
|
Start and complete plan automatically? |
This check box is checked by default. This means that all tasks in the plan are automatically created, and their due dates computed, when the delivery plan begins. If you uncheck the check box, then the Project Manager assigned must take action before the delivery plan goes into effect. When the delivery moment begins only one task is created—the MONITOR task. That task presents a button labeled “Start Plan”. This allows the Project Manager to “staff” the plan (using the Staffing page on the MONITOR task). On that page the Project Manager can reassign any performing position, person, or queue in the delivery plan. When the Project Manager has finished Staffing the plan, they click Start Plan, which initiates the first tasks in the delivery plan. Until that button is clicked, tasks are in “Staffing” status. |
|
Allow future delivery |
Check this to allow end users to request a service in advance of when service delivery should begin. Once this option is checked, the end user sees a bar across the top of the ordering page which allows them to choose the date they want the service delivery to begin. End users cannot specify the due date/completion date for a service. If the user selects a future delivery date, Service Catalog holds the order in a waiting state until the date chosen by the user. Beginning on that date, the service delivery process begins, and proceeds as configured. |
|
Notify when plan cancelled |
Allows the service designer to configure an email to be sent when the Project Manager cancels delivery of a service. |
|
Working hours per day |
Used to convert hours to business days for the Standard Duration. See the Configuring Delivery Tasks and Configuration Table to Define Delivery Activities for a Task table to set the Standard Duration and Display Units for the service. |
Defining Delivery Tasks
The table below summarizes the fields on the Task table.
|
Field |
Description/Usage |
||
|---|---|---|---|
|
New |
Add a new task to the delivery plan. |
||
|
Up Down |
Change the order of tasks in the task list. |
||
|
Indent Outdent |
Group or ungroup tasks. For example, if you create a task and click Indent , the task becomes a subtask of the task above it.
|
||
|
Delete |
Delete a task (and all subtasks beneath it). |
Defining Delivery Activities for a Task
To define detailed delivery activities for a task or series of tasks:
|
Field |
Description |
||
|---|---|---|---|
|
Workflow Type |
The default is Internal. This is the only option displayed for a site that has no Service Link integrations defined with external systems and no Service Item tasks. Choose Internal if the task is executed within Service Catalog. Choose the appropriate External option if the task is executed in an external application (not within Service Catalog). For external tasks only, an ellipsis (...) button appears next to the Workflow Type after you have saved the task. See the Configuring an External Task for more information. Choose Service Item Task if you are using Service Item Manager module to design service items and track these items. More information on service item tasks is given in the Defining Service Item Task in a Delivery Plan and in Managing the Services and Attributes. Choose Queue Service Request to publish the Service Request data to a rabbitmq message broker server. An external system subscribed to rabbitmq broker and the specific exchange will receive the message and can execute its own work flow. Choose NsApi Task to grant or revoke permissions for a service item or multiple service items that are created using grid dictionaries within the service delivery plan. For more information, see Creating Service Delivery Tasks for Granting and Revoking Permissions for a Service Item. Choose Directory Task if the operation is for adding or updating Organization Designer entities (organizational units, people, queues) or Service Link agents. See Defining Delivery Tasks for more information. |
||
|
Task name |
A brief title for the task. This appears as the subject of the task in Service Manager. The delivery task name may include the service name, using the #Name# namespace. Service data (#Service.Data....#) can also be used. Using form data for a task name allows task performers to more easily differentiate tasks in Service Manager. However, it presents challenges in the reporting modules, since the task would no longer be automatically groupable by the task name; report designers would need to use “Custom Groups” to aggregate by such tasks. It may also require administrators to configure Service Manager to allow “contains” searches, which may adversely affect performance. Service designers should think carefully before including form data namespaces as part of a task name. |
||
|
Create Agent |
After you have saved the task, a Create Agent button appears. Click this button to use the Integration Wizard. See the Cisco Prime Service Catalog Adapter Integration Guide for complete details.
The Integration Wizard automates many of the steps involved in implementing an integration. It is available only for creating integrations between Service Catalog and web services. The Integration Wizard works by retrieving the Web Services Description Language (WSDL) and operation to be invoked by the web service integration. Based on that definition of the integration, the Integration Wizard creates:
|
||
|
Subtasks execute |
Use the drop-down menu to choose the order in which any “child” tasks of this task execute: one after the other (sequentially) or at the same time (concurrently). Child tasks (subtasks) become active (ongoing) in the delivery plan, and must be completed before their parent task becomes active. If child tasks are executed sequentially, the service duration includes the durations of all such tasks. If tasks are executed concurrently, the service duration includes the maximum duration of any child task. |
||
|
Duration |
The expected length of time between when the system says the task is active (begins) and when the task is completed, rounded to two decimal places. For example, if installing a software program only takes one hour, you might give the performer a duration of 16 hours to finish the task, as the performer's workload and priorities may vary throughout the course of two workdays. The Duration value is not visible to the customer or performer, but is used to calculate the due date for the task. |
||
|
Effort |
The actual length of time it should take the performer to complete the task, rounded to two decimal places. For example, it might take one hour to install a software program. While Duration is “total elapsed time”, Effort is “time on task”. The Effort value is not displayed to any users or used in due date calculations; it is used instead as an Internal Productivity Target. |
||
|
Priority |
Set the task priority to low, normal, or high. No system behavior is tied to the priority for a task, other than a flag which is visible in Service Manager.
|
||
|
Condition |
A conditional statement allows tasks to be initiated or skipped based on the whether the expression used in the condition evaluates to true (include this task) or false (skip the task). The expressions are formulated using the namespaces and operators documented in Namespaces. After you enter an expression, click Validate to make sure that the expression is correct. Validation checks if:
The message “unexpected token” indicates that the namespace used is not valid in this context or, perhaps, that you have forgotten to enclose an alphanumeric literal in quotes. If a condition has been entered, you must decide when that statement will be evaluated. The condition for each task (approval, review, or delivery) can be evaluated either:
Use a condition that always evaluates to false (for example, “1=2”) in a conditional statement to specify a task that will automatically be skipped. The most common use cases for this are:
|
||
|
Allow a scheduled start date |
To make the task a delayed task, check Allow a scheduled start date .Then,in the Form data for start date field, do one of the following:
For more information about delayed tasks, see System Behavior for Scheduled Start Tasks. |
||
|
Form data for start date |
If you have checked the “Allow a scheduled start date” option, you may enter form data for the start date and click Validate . |
||
|
Evaluate condition when delivery phase starts |
If you have specified a condition, click the option button to indicate when the condition will be evaluated. Choose this if you want the condition to be evaluated when the delivery moment starts for this service. This means that the information required to correctly evaluate the expression must be available before the delivery moment begins. Each authorization or review has its own moment; all delivery tasks are performed within the Service Delivery moment. Authorization tasks are always serial. You could put one conditional on one task saying if field = “x” and a conditional on another saying field < > “x”. That way, you know one authorization task will always be executed, and if you choose “when authorization phase starts” only one authorization task will appear in the process view. If you choose “when task becomes active” both tasks would be displayed, but one would be skipped. The “if conditions evaluate to “false”, times will be computed as zero” statement means that Service Catalog will evaluate the conditions at the beginning of the phase. If these conditions are false, then the corresponding tasks will not be executed, and the Due Date for the service will be calculated without including the duration of these tasks. |
||
|
Evaluate condition when task becomes active |
If you have specified a condition, click the option button to indicate that the condition must be evaluated only when the delivery process has reached this task in the delivery plan. Service Catalog evaluates the condition at the beginning of each task. If the condition is false, the corresponding task will not be executed. Durations for any task configured with this option will be used to calculate the due date upon submission. |
||
|
Re-evaluate expressions as plan advances |
This feature enables you to dynamically change the performer assignment for a task, as well as the name of the task, based upon form data. This is useful if you have designated that a task name or a performer assignment should be derived from a namespace expression using form data, and when the form data will be changed during the delivery process. Setting this flag specifies that the expression should be evaluated when the task becomes active (not when the entire delivery plan is initiated). If this option is not checked, all information used in expressions in the authorization task must be present during the Ordering moment. The Re-evaluate Expressions feature is useful for designs in which there are multiple sequential authorizations or tasks. It enables the person performing a task to enter information in the service form that is used to recompute the expression used to assign the performer for a subsequent task. This feature allows dynamic assignment of a task to a user (person or queue) and dynamic adjustment of the task title. Once the task becomes active, the expression is evaluated and the task is assigned appropriately.
|
||
|
Do not allow cancellation of service after task starts |
If you select this check box, the customer will no longer be able to cancel the service after this task becomes active. For example, check this if the task will cause the delivery team to incur substantial costs or take an action that is not easily reversible. The “Cancel” option in My Services is deactivated once the delivery team begins this task. |
||
|
Display Effort subpage on a delivery task |
If you check this box, an “Effort” subtab for a delivery task is shown in Service Manager. |
Defining Service Item Task in a Delivery Plan
This section covers the functions of service item tasks. The Service Item Manager module allows designers to designate certain items to be “service items”, history can be tracked within Service Catalog. Typical service items might be a laptop; desktop; software license; or any corporate asset that can be uniquely identified and whose usage (and ownership) should be tracked. A Service Item Task can be used only when the service includes a Service Item-Based Dictionary (SIBD).
| Step 1 | Choose . |
| Step 2 | Click the
ellipsis (...) that appears next to the Workflow Type.
The Service Item Task Parameter popup window appears. |
| Step 3 | Choose the SIBD to use. |
| Step 4 | Select Update Status Only check box if the operation should modify only the Status attribute value of the service item. |
| Step 5 | Choose the operation to be applied from the Operation drop-down list |
| Step 6 | Click OK to save the task definition and dismiss the popup window. |
| Step 7 | If the SIBD is
a grid dictionary and the grid rows should be processed conditionally based on
certain field values, enter the condition expression in
Process Grid Row, click
Validate, and then click
OK.
See Configuring an External Task for syntax and example for a condition expression. |
Service Item Subscription Processing Rules
The customer and organizational unit information within the Service Item Subscription table can be set independently from that of the requisition:
- If no subscription information is provided in the create operation, the item is assigned to the customer of the requisition and that person’s Home Organizational Unit.
- If only the Customer ID is specified at the time a service item instance is created, the Organizational Unit ID of the item is set to the home organizational unit of the customer.
- If a value is provided for either the Customer ID or Organizational Unit ID, that value is used to update the service item subscription. If that value is either null or zero, the corresponding subscription field is set to null. The absence of a property in the service item-based dictionary means no change/override on the attribute value.
- Requisition ID and Requisition Entry ID provided in the dictionary are ignored and will not be used to update the subscription record.
The possible combinations for customer and organizational unit assignment and the outcome are summarized as follows:
|
When service item is created |
|||
|---|---|---|---|
|
Service Item-Based Dictionary Field |
Resulting Subscription |
||
|
Login Name |
OU Name |
Customer |
OU |
|
None |
None |
Customer of Requisition |
Home OU of Customer |
|
None |
Blank, Inv alid Value, or Zero |
Customer of Requisition |
NULL |
|
None |
Valid OU |
Customer of Requisition |
OU provided |
|
Login Name |
OU Name |
Customer |
OU |
|
Blank or Invalid Value |
None |
NULL |
Home OU of Customer |
|
Blank, Invalid Value, or Zero |
Blank, Invalid Value, or Zero |
NULL |
NULL |
|
Blank, Invalid Value, or Zero |
Valid OU |
NULL |
OU provided |
|
Valid Customer |
None |
Customer provided |
Home OU of Customer |
|
Valid Customer |
No Value |
Customer provided |
NULL |
|
Valid Customer |
Valid OU |
Customer provided |
OU provided |
|
When service item is updated |
|||
|
Service Item-Based Dictionary Field |
Resulting Subscription |
||
|
None |
None |
No change |
No change |
|
None |
Blank, Invalid Value, or Zero |
No change |
NULL |
|
None |
Valid OU Name |
No change |
OU provided |
|
Blank, Invalid Value, or Zero |
None |
NULL |
No change |
|
Blank, Invalid Value, or Zero |
Blank, Invalid Value, or Zero |
NULL |
NULL |
|
Blank, Invalid Value, or Zero |
Valid OU Name |
NULL |
OU provided |
|
Valid Customer |
None |
Customer provided |
Home OU of Customer |
|
Valid Customer |
Blank, Invalid Value, or Zero |
Customer provided |
NULL |
|
Valid Customer |
Valid OU Name |
Customer provided |
OU provided |
Service Item Task Operations
Service item task operations instruct Service Catalog to create, update, or delete a service item. The service item task is executed as specified by its sequence in the service’s workflow.
- Creating a Service Item: All
custom operations are "Update" in nature. All the points here apply
to them as well i.e when a service item task with an operation type of “Create”
is executed, Service Catalog:
- Creates an entry for the service item in the Service Item tables. The entry includes all attributes of the service item for which data has been supplied via the service form.
- Creates an entry for the service item in the Service Item Subscription table. This table records all service items and their current status.
- Records the customer, current request, the date and time the request was submitted, and the date and time the service item was created.
- Creates an entry for the service item in the Service Item History table. This table records the requisition that created the service item.
- Updating a Service Item:
When a service item task with an operation type of “Update” is executed,
Service Catalog:
- Updates the existing entry for the service item in the Service Item Knowledge Base tables.
- Updates the entry for the service item in the Service Item Subscription table to reflect the changed status of the service item.
- Creates an entry for the service item in the Service Item History table. This table records all operations (and the requisition in which the service item task occurred) that affected the status of a service item.
- Deleting a Service Item: Deleting a service item removes all traces of the service item, erases all references to the item from the system, including its history. In some scenarios, it might be better to include an attribute in the service item to mark it as “Inactive” or “Defunct”, and to write conditional rules that prohibit provisioning such items.
For more information on service items and service item tasks, see Chapter 9,Managing the Services and Attributes.
Configuring an External Task
This section covers the workflow type for external service item tasks,i.e, the tasks performed outside the Service Catalog.
Defining External Tasks in the Workflow
By default, the drop-down list for Workflow Type contains only one entry, “Internal”, indicating that the task will be performed within the Service Manager module. If integration specialists have used the Service Link module to define “agents” that integrate with external systems, the action associated with each agent also appears in the drop-down list.
For example, the workflow type for the “SAP Integration” agent might be displayed as “Send data to SAP”; the workflow type for an agent that integrates with “Remedy” might look like “Send Ticket to Remedy”.
 Tip | Contact your site administrator to obtain details about the services and tasks integrated with Service Link. |
For external tasks only, an ellipsis (...) appears next to the Workflow Type after you have saved the task.
If you have permissions to the Service Link module, you can click the “...” button to access the Agent Parameter Override dialog box. This dialog box includes settings that show how the data to be sent to the external system is mapped to fields on the service form or other data about the requisition. If you have permission to change these settings, the dialog box is editable, otherwise it is read-only. For more information on permissions for Service Link, see the Capabilities for Service Link section of Cisco Prime Service Catalog Administration and Operations Guide .
External Service Item Task Operations
Once an external service item task becomes active (that is, has a status of Ongoing) in the workflow, Service Link listens for the incoming requests to create, update, or delete service items. The changes made to the service item repository are similar to those of internal service item tasks. The channel ID of the inbound requests allow Service Link to identify the service request to be used for tracking the service item history.
You can perform other task updates that are typical of external tasks—for example, adding comments and sending parameter updates—through the incoming requests as well. When all service item operations are processed successfully, you must be sure to send a “done” action to complete the task so that the next task in the delivery plan can be triggered.
For more information about the Service Item Listener Adapter and the specification of inbound service item messages, see the “Designing Integrations with Service Link Standard Adapters” chapter in the Cisco Prime Service Catalog Adapter Integration Guide is not recommended because the reconfigure action may disrupt processes that are currently running on the machine. Certain actions are, in fact, prohibited if they were to be performed through the VMware Infrastructure Client. Therefore, service designers need to add a “power off” task BEFORE the “reconfigure” task. This ensures that the subsequent request to reconfigure the virtual machine may proceed. If the virtual machine is already down upon receipt of the power off task, the power off task fails, but this failure is harmless and does not impede the progress of the reconfigure task.
Defining Directory Tasks in the Workflow
Directory tasks can be used to create or update people, organizational units, or Service Link agents using form data. If the operation fails, the task is marked as complete and an error message is written to the service form.
Any free form dictionaries that contain the required fields can be used with the directory task. The dictionary should also include a text field named “ErrorDescription” for capturing any errors returned from the operation. Consider hiding this field while ordering, and using the value of this field to conditionally trigger manual tasks for error handling.
Directory tasks can also be used with grid dictionaries to process multiple occurrences of the same object type (e.g., create multiple organizational units). The task loops through all rows in the grid dictionary and performs the operation for each of them. If exceptions are encountered for some of the occurrences, the error messages are logged into the ErrorMessage field for those grid rows and do not affect the successfully completed ones.
You can also design condition expressions using operators such that the application evaluates the condition on each row and proceeds with the operation if the condition is satisfied.
Syntax for condition expression: Data.<DictionaryName>.<FieldName>
Example of a condition expression: (Data.ouDict1.Type = "Service Team" and Data.ouDict1.Description="abc") or (Data.ouDict1.Type = "Business Unit" and Data.ouDict1.Description="xyz")
Although the syntax used here is identical to that for delivery tasks, only dictionary namespaces are supported for the Process Grid Row conditional expressions. Requisition, task or service-specific namespaces are not applicable to this context.
To configure a Directory Task:
The following operations are supported for directory tasks. The required and optional fields for directory operations are listed in Operations Supported for Directory Task table:
|
Operation |
Dictionary Fields |
Remarks |
||
|---|---|---|---|---|
|
Input: (* Mandatory for Create operation) Name* – Text(100) Email_Address* – Text(100) Home_Organizational_Unit* – Text(200) Timezone* – Text (50) Output: Person_ID – Text(50) Organization_ID – Text(50) ErrorDescription – Text(80) |
Create a new queue or perform an update if the queue already exists. Organizational units or groups referenced are created automatically if they do not exist in the system. The value for the Timezone field should be in the form of the short name as seen in the Time Zone selections in Organization Designer, for example, “America/Los_Angeles”. The values for Person_ID and Organization_ID fields are updated back to the request form when the queue or Home OU are created. |
|||
|
Input:Login_ID – Text(50) Output: ErrorDescription – Text(80) |
Modify the status of a person to “Active” or “Inactive” accordingly |
|||
|
Create New Organizational Unit |
The Dictionary fields supported are: Organization_ID, Name*, Description, Type*, Parent_Name, Parent_Type, Billable, Parent_Description The ID of the created Organization is returned to the form in the Organization_ID field. |
If you select this operation in the directory task workflow, you can enable the user to create a new organizational unit as a task during the service workflow. The user does not need access permissions for the Organization Designer Module. While the task is being executed, Parent_name field already exists in the order form where you can add a parent name. Application either creates a new parent if the parent does not exist or associates it with the existing parent. The ID of the created Organization is returned back to the form in the Organization_ID field. |
||
|
Input: (* Mandatory for Create operation) First_Name* – Text(50) Last_Name* – Text(50) Login_ID* – Text(50) Password* – Text(50) Email_Address* – Text(100) Home_Organizational_Unit* – Text(200) Timezone* – Text(50) Is_Locked LoggedIn_UserPwd Organizations – Text(4000) Groups – Text(4000) Roles – Personal_Identification – Text(512) Title – Text(100) Social_Security_Number – Text(100) Notes – Text(4000) Company_Code – Text(200) Division – Text(200) Business_Unit – Text(200) Department_Number – Text(200) Cost_Center – Text(200) Management_Level – Text(200) Region – Text(200) Supervisor_ID – Text(200) Employee_Type – Text(200) Location_Code – Text(200) Company_Street_1 – Text(100) Company_Street_2 – Text(100) Company_City – Text(100) |
Organizational units or groups referenced are created automatically if they do not already exist. The values for the Person_ID and Organization_ID fields are returned to the service form when the person or Home OU are created during the operation. The value for the Timezone field should be in the form of the short name as seen in the Time Zone selections in Organization Designer; for example, “America/Los_Angeles”. The input type for the Organizations, Groups and Roles fields should be set to “select (multiple)” in the Active Form Component used. In an Update operation, the Login_ID field is used to look up the person record. Person attributes absent from the dictionary are excluded from the update. If an user’s account is locked due to retry policy violation the IsLocked field is enabled automatically. To unlock the user account, disable the IsLocked field and then reset user password. Enter the LoggedIn_UserPwd only if you are creating a user or changing a user password. |
|||
|
|
Level – Text(100) Cubicle – Text(100) Personal_Street_1 – Text(100) Personal_Street_2 – Text(100) Personal_City – Text(100) Personal_State – Text(100) Output: Person_ID – Text(50) Organization_ID – Text(50) ErrorDescription – Text(80) Personal_Postal_Code – Text(100) Personal_Country –Text(100) |
External User Authentication (EUA) allows to override default authentication mechanism within Prime Service Catalog and authenticate a user against an external source. If EUA is not enabled or if you are using a backdoor url the authentication for password change in user profile, the LoggedIn_UserPwd fields must contain the database password of the logged in user trying to change the password. If EUA is enabled you must use the LDAP password in the LoggedIn_UserPwd field. An error is returned if: |
||
|
Update Organizational Unit |
Name* Type* Description Status Billable ErrorDescription If you need to modify the type of OU, then add a field named '”Change_Type”'. |
|
||
|
Rename Organizational Unit |
Name* New_Name* Type* ErrorDescription |
|||
|
Activate/Deactivate organizational unit |
Name* Activate* Type* ErrorDescription |
The Activate field should be set to "true" or "yes" for updating the organizational unit status to “Active”, or to “false” or “no” for updating the status to “Inactive”. |
||
|
Update existing agent properties |
Name* |
This feature enables you to order a service with a directory task operation that updates inbound and outbound agent properties.
|
||
|
Create account / update account |
Ensure that the dictionary you associate with the directory task workflow for this operation has the following fields: Name* AccountType* Description BillingRateGroup OrganizationalUnit ErrorDescription |
1) The maximum length for Name is 100 characters. 2) AccountType value should be “Project Account “or “Tenant Account”. 3) The maximum length for Description is 500 characters. 4) The Organizational Unit field takes the input of a multi-select box and the values are assumed to be of type “Business Unit”. For tenant accounts, only one organizational unit may be specified. 5) Functional positions and custom attributes cannot be specified at this time. |
||
|
Create agreement |
Name* AccountType* Account* AgreementTemplate* Description ErrorDescription |
|
Configuring AMQP Tasks for Publishing Service Request to an External System
Prime Service Catalog allows you to publish the service request to another application or system using Advanced Message Queuing Protocol (AMQP). AMQP provides standards on how messages should be structured and transmitted between platforms or systems.
 Note | To prevent Poodle security attack, Prime Service Catalog in 11.0 and later, supports connection to RabbitMQ only via TLS 1.2 protocol, hence consumers are also required to use TLS1.2 to connect and consume the messages. Therefore, to connect and consume these messages from RabbitMQ server, use only TLS1.2 . |
A task type called Queue Service Request is available under the workflow type, which is used to publish the service request to another application or system.
Queue Service Request consists of a pre-task, main task, and a post-task that are executed in order. The Service Designer provides the option to enable or disable a pre task and post task that will be executed before and after the main AMQP task. A main task alone can be executed without having a pre and post task. For more information on AMQP, see Cisco Prime Service Catalog Integration Guide.
| Step 1 | Choose . | ||
| Step 2 | Choose Queue Service Request as the Workflow Type. | ||
| Step 3 | Enter the Task Name. | ||
| Step 4 |
Save the
plan.
| ||
| Step 5 | Click the ellipsis (...) that appears next to the Workflow Type. | ||
| Step 6 | In the Queue
Service Request Parameter popup, do the following:
|
Configuring AMQP Tasks for Publishing Request to Cisco Process Orchestrator
| Step 1 | When a service is ordered in Prime Service Catalog, it generates nsXML or JSON output and publish this output to the AMQP Server. | ||
| Step 2 | AMQP server secures this nsXML message with Public key. For more information on this, see Encrypting AMQP Tasks. | ||
| Step 3 | Cisco Process Orchestrator reads this message from AMQP server using the private key. This nsXML is passed into Cisco Process Orchestrator northbound web services, which starts a process at Cisco Process Orchestrator. | ||
| Step 4 | Cisco Process
Orchestrator makes web service calls or connects to Cisco Prime Service Catalog
through an adapter to send the acknowledgment of the message received from
Cisco Prime Service Catalog.
|
Encrypting AMQP Tasks
The Service Catalog supports encrypting every AMQP task with a public key selection. The AMQP Public Key is used to encrypt the data in a secure string format.
In the dictionary field, when the 'is-secure' attribute is set to true, the value of those dictionary fields will be converted to secure string using the public key. The format of the secure string is based on the AMQP Secure String Format that you select.
Procedure
Creating Service Delivery Tasks for Granting and Revoking Permissions for a Service Item
You can create a service delivery task to grant or revoke permissions for a service item or multiple service items that are created using grid dictionaries within the service delivery plan. This was possible only via REST call earlier.
The dictionary attributes for grant/revoke permissions must be as follows:
- recipientName
- recipientType
- recipient
- object
- objectName
- scope
- permission
- instanceName
- domain
- ErrorDescription
For more information about granting or revoking permissions for possible field values using APIs, see “Grant and Revoke Permissions API Table” in the Cisco Prime Service Catalog Adapter Integration Guide .
To create a NsAPI task to grant SIM permissions:
Creating a Scheduled Start For a Delivery Task
By default, a delivery plan becomes active (and the clock starts ticking on whether the service performers are completing tasks on time) as soon as all authorizations for the service request are completed, or, if there are no authorizations, as soon as the service request is submitted. Sometimes, this is not the desired behavior. For example, you may enter a request on behalf of a new employee scheduled to start work in a few weeks; or a development team may request a new server for a project scheduled to ramp up in the future. For such cases, Service Catalog allows you to create a Scheduled Start task, which does not become ongoing (active) until the specified start date is reached.
You can specify that a scheduled start task is executed on:
- A date and time specified on the service form by the customer or by someone performing an approval or review.
- A fixed date and time that you specify in the service’s design, on the Plan tab in Service Designer
To create a scheduled start task by using a field on the service form:
System Behavior for Scheduled Start Tasks
The system maintains both a Scheduled Start Date and an Actual Start Date for each delivery-plan task. You can see these dates on a task form in Service Manager.
The system does not automatically start a scheduled start task after the preceding task is completed. The scheduled start task has a Scheduled status until the specified starting-point is reached. At that point, the system changes the task status to Ongoing , and the task is then available for processing by the assigned performer. The “Scheduled Start” and “Started on” fields are the same for a scheduled start task.
If the starting-point for a scheduled start task is defined from form data, and you use a Date field to define this point, the system sets the time to the working hours of the task’s performer. For example, if the task is to be performed by the HR Group queue and that queue’s working hours are from 8:00 to 16:00, the system sets the time to 8:00 on the date entered by the user.
The system schedules all delivery-plan tasks after the Service Delivery phase of the workflow process begins. (The Service Delivery phase begins after the Authorization phase completes.)
The system does not evaluate the starting-point specified for a scheduled start task until it is scheduling all the delivery-plan tasks at the start of the Service Delivery phase. You may want to take advantage of this when designing services, as it means that the starting-point may also be specified by the performer of an authorization or review step (as opposed to the customer who orders the service).
As a service designer, you cannot control what the customer enters as the starting-point for the scheduled start task. For example, the customer might enter a future date that ends up occurring before preceding tasks in the service are completed. If the start date specified by the customer for a scheduled start task is earlier than the earliest possible starting date (with respect to the rest of the plan), the system ignores the specified start date and treats the task as if it were not a delayed task. This is logged in the System History with a comment indicating that the start date is ignored.
Defining Task Participants
| Step 1 | Choose . |
| Step 2 | Specify who completes the task and, optionally, how the work is supervised. For more information, see Fields to Define Task Participants. |
| Step 3 | Click Save to save your changes on this tab. |
Defining Email Notifications for Delivery Tasks
Several events are associated with each task. By associating an email with each event, you can notify the service’s customer, task performer, or other groups or individuals of the current status of the request.
Choose Service Designer > Services > Plan > Tasks > Email subtab to specify which notifications should be sent in response to which event. The notification must be defined using the Notifications component of the Administration module. Although Service Catalog is shipped with some default email templates, most sites prefer to design custom notifications.
For each task in the delivery plan (and for each authorization or review), the designer can choose the number of tiers in the escalation structure to be used by that task.
For example, you might configure three escalation tiers:
- Tier 1: 1 hour after the task becomes late
- Tier 2: 8 hours after Tier 1
- Tier 3: 16 hours after Tier 2
The Maximum Tier setting determines how many of the escalation tiers are to be used by that particular task, starting with the first tier.
- As much as there are in escalations = all tiers
- Specified As = the number of tiers to use for this task; any number less than or equal to the number of tiers defined.
In this case, for example, if the maximum tier is Specified As 2, notifications would be sent 1 hour and 9 hours after the task becomes late; the third tier escalation would not be applied.
Adding Task Instructions
Choose subtab, to give instructions for the task or set the link to any task instruction-related URLs.
|
Field |
Description |
|---|---|
|
URL |
Enter the full URL beginning with “http://” you wish to link. |
|
URL Description |
Enter a brief description to explain what the user will see when they link to the URL, or to include HTML in the checklist item. For example: <a href=”URL">Click Here</a> for more information on how to complete your task. |
|
Task Instructions |
Use this text field to enter task instructions, if desired. |
The HTML editor can be used to introduce HTML into the URL Description and Task Instructions fields.
Creating Checklist For Completing a Task
You can create a list of reminders or detail the specific procedural steps for completing a task using checklists. These appear in Service Manager as a checklist, detailing procedural steps for completing the work. Checklists do not affect due dates and are not reportable.
| Step 1 | Choose . |
| Step 2 | Click Add New to add new items to the list by entering the checklist item in the Item Properties box to the right. |
| Step 3 | Use the Fields in Checklist tab table to further configure checklists. |
Field
Description
Items
The items
in this list comprise the checklist the performer sees in Service Manager.
Use the
Up or
Down Arrows
to rearrange the item order. Items at the top should be performed first.
Name
Enter the
name for the checklist item.
Make
checklist items mandatory for task completion
Check
this option to make all the items mandatory for completion of the task. This
means the person performing the task will not be able to close out the work for
the task until they have checked all of the items in the checklist in Service
Manager.
Configuring Escalation Email for Delayed Tasks
You can use the Plan > Escalations subtab to specify the email notifications sent to performers, supervisors, and customers when an activity is late.
To define escalation tiers:
Designing Service Delivery Workflows
Service Catalog offers two approaches to design the workflow of tasks that comprise the delivery plan:
- Use the Task area at the middle of Plan tab to enter tasks, in conjunction with the buttons available (Indent, Outdent, Up, Down) to configure the workflow so that tasks execute in the appropriate order and are grouped correctly.
- Use the Graphical Workflow Designer, available from the Graphical Designer tab, to draw the workflow by dragging and dropping tasks, connectors, and subtask groupings onto the drawing area.
The diagram to specifies the tasks and subtasks and their relationship. It comprises the delivery plan, the sequence in which they are executed, and whether execution is sequential or concurrent.
A workflow can be configured using either tool, and, in fact, service designers can switch back and forth between Graphical Designer and the dialog boxes provided on the Task tab. The Graphical Designer provides the workflow for the tasks, and its property sheet allows users to enter most general information about the task as well as the performer’s role. Other individual task details, such as emails associated with task fulfillment, checklists, and task participants must be supplied by using the subtabs of the Plan tab.
.
- About Graphical Workflow Designer
- Creating a Delivery Plan using Graphical Designer
- Graphical Designer vs. Plan Tab
About Graphical Workflow Designer
The Graphical Workflow Designer allows service designers to drag and drop tasks, name them, and connect them. The Graphical Designer also provides the ability to define parent/child relationships among tasks. An accompanying Task Properties sheet allows specification of additional details about the task definition and execution.
The Graphical Designer provides a visually oriented alternative to designing the service’s delivery plan by using the dialog boxes provided in the General tab for the delivery plan. Designers can define tasks and specify the workflow between them using either method, and freely switch back and forth between the Graphical Designer and the dialog boxes.
The Graphical Designer provides a simplified view of the delivery plan. To configure the more advanced details of a plan (such as those available on the Participants, email, Task Instructions, and Checklist sub tabs), switch to the Plan tab. For more information see, Configuring Delivery Tasks.
The Graphical Designer pane has the following sections:
|
1 |
Tools Pane |
4 |
Outline Pane |
|
2 |
Toolbar |
5 |
View Tools |
|
3 |
Work Area |
|
|
- Tools Pane, at the top left, contains building blocks of the workflow designer. These building blocks can be dragged and dropped into the work area and connected to create a complete workflow.
- Toolbar contains the buttons for saving the delivery plan; printing the plan; and manipulating the contents of the work area.
 Note | Legend lists the color coding used to represent objects included in a workflow diagram |
- Work Area holds the workflow diagram. When the Designer is invoked for a new delivery plan, the work area is blank except for the bright green circle, which denotes the start of the plan.
- Outline Pane, in the middle of the left side of the page, gives a high-level overview of the diagram.
- View Tools: Zoom/Layout buttons, at the bottom left, allow the designer to magnify or reduce the size of the workflow diagram or to alter the diagram’s orientation.:
About Tools Pane
The Tools Pane includes tools for adding the basic types of objects that comprise a workflow to the diagram.
|
Option |
Explanation |
|---|---|
 |
A workflow consists of a series of tasks, arranged in sequence. Use the Task tool to add a task to the workflow. |
 |
Tasks can be grouped as child tasks to a parent task. |
 |
Use the Associate tool to specify the sequence of tasks and to associate parent with child tasks. |
In addition to the options in the Tools Pane, context-sensitive task cursors are available to help manipulate the content of the diagram. As you move the mouse over tasks previously placed on the diagram, the cursor changes shape, to indicate which actions are available:.
|
Cursor |
Explanation |
|---|---|
 |
Once an object has been selected, the select-cursor appears. Any objects marked with the select cursor are subject to the next Copy, Move, or Delete command. |
 |
The connect cursor allows you to associate the highlighted task with another task. With the connect cursor displayed, drag the mouse to the task to be connected to the current task. When you release the mouse, a task sequence (association) is established. |
Creating a Delivery Plan using Graphical Designer
To create a delivery plan using the Graphical Designer, edit the service in Service Designer, click the Plan tab, then click the Graphical Workflow subtab. The work area appears empty except for the “Start Workflow” icon.
| Step 1 | Define a task
|
| Step 2 | Specify
workflow
|
| Step 3 | Create Parent
Tasks and Subtasks
Tasks may be grouped for several reasons. For example: Some of the tasks are conditional, and you want to send an email notification when the first or last task in the series completes, regardless of which specific task is executed. A task should be performed concurrently with a second task. In computing the Service Level Agreement (SLA) for the service, you do not want to count both tasks, just the one that would take the longest. To account for these and other scenarios, Service Catalog supports grouping tasks. A parent task may have one or more children or subtasks. The subtasks may execute either consecutively or concurrently. |
| Step 4 | Save a Workflow
You can only save valid workflows. If any alert icons appear on the diagram, it indicates the workflow is not valid. You can hover the mouse over the alert icons to get a detailed description of the problem; it will usually be that the elements of the diagram are not properly connected to each other. Once the error has been corrected, click Save again to save the workflow. Whether you use the Graphical Designer or the Plan tab dialog boxes, Service Catalog saves the workflow exactly the same way. This approach is good, in that you can use whichever tool is most convenient for you. But Service Catalog does not save the diagram itself—it reconstructs it from the delivery plan previously saved, and then adds to that delivery plan as you continue to work on the diagram. You can customize the appearance of the workflow for printing, for example, by moving tasks or increasing the size of a task icon, to show a longer description. However, any such changes are removed when the diagram is saved, and the workflow reverts to its default layout (horizontal or vertical). |
| Step 5 | Print the
Diagram
Click the Print option from the toolbar to print the diagram. The printer-friendly version will reflect the current view of the diagram, including its scale and orientation. If required, the diagram can span multiple pages. Use the standard browser File > Print command to print the diagram. It is possible to make manual changes to the diagram, for example, to change the size of an individual task icon. If such changes have been made, they are reflected in the printer-friendly version. However, all such changes are temporary, and are not saved when the workflow is saved. |
Graphical Designer vs. Plan Tab
There are certain things the Graphical Designer does more efficiently than using the dialog boxes in the Plan tab. For example, it is much easier to change the sequence of tasks, simply by reconnecting one task to another, in the Designer than it is by moving rows of data up and down.
The Graphical Designer includes an option to print the diagram. You will need to compare that printed version to the service preview available in Catalog Deployer, which includes the detailed workflow in textual format, to see which better suits your needs. Perhaps a user presentation will call for the printed diagram, while developer documentation is better served with the Catalog Deployer preview.
To specify the general task properties, designers can use either the Plan tab or the Graphical Designer. Most of the same properties appear on both the Task Properties sheet in the Graphical Designer and the General subtab for the task. However, the General subtab dialog boxes have the following advantages:
- Although you can enter a conditional expression and form data for scheduled start date in both places, only the General subtab dialog boxes include the option to Validate the expression or namespace entered. Validating at design time is generally preferable to seeing the error for the first time when you test the form.
- The way you connect the subtasks to the Start Subtask icon determines whether the parent task is defined so that “subtasks execute sequentially” or “subtasks execute concurrently”. It may be easier to simply change the “Top Level Tasks Execute” attribute of the parent task definition in the General subtab than having to reconnect all the subtasks in the diagram.
You will always use the Plan tab dialog boxes to complete the definition of the delivery plan, to specify the participants, task instructions, email notifications, and checklists for tasks as required.
Tasks are typically not assigned to a particular person, but rather to a queue or functional position. In this way, multiple people are available to work on the task, and it will not be delayed if one person is unavailable.
Configuring Authorizations
The Authorizations tab is used to configure authorization, review, and escalation tasks for the service and to specify the order in which these occur. You can also customize the escalation tiers, recipients, and email messages for late authorization/review tasks for a service.
For each service you can choose from three options:
- Use service group authorization structure only: The service inherits the authorization structure defined for the service group (specified in Administration > Authorizations); no additional configuration is expected. See the Site Administration chapter of the Cisco Prime Service Catalog Administration and Operations Guide for more information.
- Use service-level authorization structure only (will not use service group-level): Any authorizations defined for the service group are ignored. Only authorizations configured for the service are applied.
- Use both service group-level and service -level authorization structures: Accepts the authorization structure defined for the service group, and allows you to supplement it with a customized scheme for each service.
This section covers the following:
- Authorization Types
- Using the Site Authorization Scheme
- Configuring Authorizations for use with Service Link
Authorization Types
The Authorizations and Reviews subtabs are where you determine who should authorize or review the service. You can set up unique roles and define the order in which these roles review and approve request.
- Authorizations give the approver the opportunity to determine if the person requesting the service is eligible to receive it. If an authorization is rejected, the process stops and the service is not delivered. If multiple authorizations are defined, they are performed sequentially in the order in which they are specified—one authorization cannot be started until the previous is approved.
- Reviews are for information only. A reviewer cannot reject a service or cancel the delivery process, only indicate that he/she has reviewed the service. If multiple reviews are specified, they are performed concurrently. However, the delivery process will not proceed until all reviews have been completed.
Note | Based on the authorization type you choose, either the Authorizations – Sequential Process or Reviews – Concurrent Process subtab appears. |
- The Up and Down Arrow buttons to the right of each role allow you to move the role up or down in the approval process.
Configuring authorization, reviews, escalations tasks
| Step 1 | Choose . |
| Step 2 | Choose an Authorization Structure and Authorization Type. |
| Step 3 | Choose
Review-Concurrent Process to define the review process.
Select the check box to the left of the Name field to the authorization role.
To add a review or escalation, choose appropriate review- Concurrent Process or
escalation- Concurrent process appropriately and click
Add.
To Update a review or escalation, choose a previously defined authorization/review role by checking the check box to the left of the Name field. |
| Step 4 | Add or update the details using Fields in Reviews Table. |
| Step 5 | Click Save or Update as appropriate. |
Field
Definition
Name
Name given
to the authorization role.
This role
name does not appear anywhere else in the application.
Subject
The title
for the authorization/review task that this role performs. The entry here
appears in the My Authorizations portlet that authorizers and reviewers see in
My Services.
Duration
The
published amount of time (in hours) to perform the review or authorization.
This field exists for the purpose of letting you add some time to the amount of
time that the authorization really takes.
For
example, you estimate that an authorization in the service group that you are
configuring takes 0.5 hours. However, you want to add some time to the
“official” estimate displayed in My Services. Therefore, you enter 1.0 hours in
this field, and 0.5 hours in the Effort field.
Effort
The actual
amount of time expected to be expended on this authorization.
Assign
Options to
assign the default reviewer/approver from:
Assign to
Specific
person, queue, title of functional position, or conditional expression,
depending on what you chose in the “Assign” field.
Use the
“...” button to choose the specific person or functional position, or enter an
expression directly into this field.
Workflow
Type
The default
setting for the Workflow Type drop-down is “internal,” which means that the
task is performed manually by a user. To set the task so that it is performed
as an external task in a third party system, use the drop-down list to choose
the appropriate action from this list (see the
Configuring Authorizations for use with Service Link.)
Escalation
Tiers (option button)
Choice for
tiers on the Escalations subtab (see the
Configuring Escalation Email for Delayed Tasks):
Indicates
that all escalations set up on the Escalations subtab are to be used.
Indicates
that X tiers of escalations set up on the Escalations subtab are to be used.
For
example, if you have set up the Escalations tab with three tiers of escalations
and choose the first option, all three tiers are implemented if the activity is
later. If you choose the second option, specifying the number 1, only the first
tier of three is implemented if the activity is late.
Condition
Enter any
expressions containing conditions that need to be met to fulfill the review.
For
example, if you enter the following: ActualCost<=1000, then anything that
has an actual cost of less than or equal to $1000 is automatically approved by
the chosen authorization role. See
Syntax for Conditional Statements
for more details on creating conditional expressions.
Click
Validate to make sure that your expression is correct.
Service Designer indicates if the syntax of the expression is correct or has
errors. Note that this is a syntactical check only; the validate function does
not check to see if the data you have referenced is actually in the system
database.
Evaluate
condition when authorization phase starts (radio button)
The
condition set up in the Condition field becomes active as soon as the review
phase starts.
Evaluate
condition when task becomes active (radio button)
The
condition set up in the Condition field becomes active after the review phase
completes and the activity phase begins.
Re-evaluate
expressions as authorizations/reviews proceed (check box)
Configure
the system to re-evaluate expressions for the assignment of participants and
title of task following each authorization/review task. This is useful if the
participant or task title expressions change after initiating the task.
Notify
when authorization/review starts
The email
template that is automatically sent out when the review process begins; or
chooses “none”.
Notify
when authorization/review completes
The email
template that is automatically sent out when review is completed; or chooses
“none”.
Notify
when activity is cancelled
The email
template that is automatically sent out when the requester cancels the
activity; or chooses “none”.
Notify
when activity is rejected (authorization only)
The email
template that is automatically sent out when the authorizer rejects the
activity; or chooses “none”.
Notify
when task is rescheduled
The email
template that is automatically sent out when the task is rescheduled; or
chooses “none”.
Notify
when task is reassigned
The email
template that is automatically sent out when a task is reassigned.
Notify
when external tasks fail
The email
template that is automatically sent out when external tasks fail.
Using the Site Authorization Scheme
You can use the site authorization scheme as set up in the Authorizations tab of the Administration module. This is the default setting, and often is the easiest to implement. See the Site Administration chapter of the Cisco Prime Service Catalog Administration and Operations Guide for more information.
If you see the message “not currently enabled via the Administration module,” then the particular service authorization/review is not enabled for your site. This can be changed in the Administration module.
Configuring Authorizations for use with Service Link
If your business process requires authorizations to be processed through a system other than this product, you can use Service Link to have an authorization task performed by that external system. The settings required to define an external task and how it should be handled appear on the Authorization tab—in the Details screen of a role.
- The default setting for the Workflow Type drop-down menu is “internal,” which means that the task is performed manually by a user. To set the task so that it is performed as an external task in a third party system, use the drop-down list to choose the appropriate action from this list.
- If for any reason the third party application does not successfully complete the authorization task, you might want to notify an administrator that a problem occurred in the Service Link integration for this task. In the “Notify when external tasks fail” menu, you can choose a template that will send such a notification. For information about email notifications, see Defining Email Notifications for Delivery Tasks.
- If you have appropriate permissions to the Service Link module, you will see an ellipsis (...) button to the right of the Workflow Type drop-down menu. When you click this button, the Task Data Mapping dialog box appears.
This dialog box includes settings that show how the data to be sent to the external system is mapped to data on the service order form, or elsewhere in the system. If you have permission to change these settings, the dialog box is editable. Otherwise, it is read-only.
Now you are ready to set up escalation emails. See the Configuring Escalation Email for Delayed Tasks for details.
Feedback