- 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: Configuring Services and Service Bundles
Configuring Services
and Service Bundles
This chapter contains the following topics:
Configuring Services and Service Bundles
Services can be designed and grouped to organize a set of similar or related services “owned” by a particular service team in the Service Designer module. Using service groups, you can:
- Configure authorization and escalation processes for services in the group
- Configure permission to order services in the group
- Assign functional positions that are used by the group
Service group folders are different from the categories that end users browse through in My Services. The names of the service group are not displayed to an end user.
For example, to create a “Telephone Services” service group containing the services for acquiring and setting up telephone service for your organization; you need to have a service team assigned to deliver the services and have other people responsible for the management of the Telephone Services group itself. The service group specifies, who can order cellular phones and has an authorization process in place once a phone has been ordered. The Telephone Services group may also have a series of escalation messages configured to alert people when they are late authorizing or reviewing a service.
- Configuring a Service Group
- Creating a Service
- Creating Custom Templates
- Configuring Bundles of Related Services
- Defining Service Level Permissions
Configuring a Service Group
Similar services can be grouped using Service Designer module. Using groups you can configure authorization processes, ordering permissions, and escalation notifications at the service group level. For information on configuring permissions at a service level, see Defining Service Level Permissions. Service Group can be created from the Custom tab of Integrations module. For more information see section Creating Custom Integrations in Cisco Prime Service Catalog Administration and Operation Guide. After a service group is created, configure the service group such that a person or a group of people are able to manage the services in the service group.
Before You Begin
Choose an Organizational Unit (OU) or people who will review a service request, approve service request and also handle escalations.
| Step 1 | Choose
Service
Designer.
To view a service group, choose a service group name to open the details and configuration tabs for that service group, or Expand the + icon next to the service group name to see the services associated with the group. |
| Step 2 | To configure,
select the service group and do the following:
However, the ability to order services in the group must be independently assigned. For more details on difference between group level versus service level permissions, see Defining Service Level Permissions. |
You can delete a service group if you no longer need it. You cannot delete a service group in which services still exist. If services do exist, delete or transfer them to other service groups before deleting the group. To delete a Service Group, choose the service group you want to delete and click Delete in the General tab.
|
Field |
Description |
||
|---|---|---|---|
|
Name |
Enter the name of Service Group |
||
|
Description |
Enter the description of the Service Group |
||
|
Override Team Relevant for Services |
Check this option to overrides the team relevant settings on individual services belonging to the service group. |
||
|
Team Relevant |
Check this option to set all the services within the service group as team relevant. For more information, see section Making Services Team Relevant. |
||
|
Service Team |
Associate an appropriate service team for the service group. For more information see, Setting Up Services. If you change the service team assigned to a service group:
|
||
|
Functional Position |
To add a functional position:
To assign functional Position to People within the Service Group: Click the “...” button in the row of the functional position and search for the person using the Search Option. Select the person and click OK.
For more information, see Structuring Your Organization. For description about functional position, see Cisco Prime Service Catalog 11.0 Administration and Operation Guide. |
||
|
Save |
Click Save to save the changes on this tab. |
|
Workflow |
Procedure |
|---|---|
|
Configuring Authorization Structure |
Choose one of the following fields under Authorization Structure For Service Group: Use Site Authorization Structure Only: Uses only site-wide authorization structure and ignores the authorizations and reviews configured at service group or service level. Use Service Group-level Authorization Structure Only: (will not use service group-level): Allows you to develop an authorization structure based on a unique scheme of roles, order, or escalations. Use Both Site Level and Service Group Level Authorization Structures: Accepts the site-wide scheme of roles, order, or escalations, and allows you to supplement it with a customized scheme that you establish to enhance the authorization process. For more information, see Configuring Site Administration in Cisco Prime Service Catalog 11.0 Administration and Operation Guide. |
|
Configuring Authorization Types |
Choose one of the following Authorization Type:
|
|
Defining the Review and Escalation Process |
To define Reviews Concurrent Process: Click Add and enter the Name, Subject, Duration of review, Effort for each review, and person to Assign a review. Reviews are performed concurrently. Since reviews cannot cancel the delivery of a service, they are performed concurrently, to expedite the delivery process. To Define Escalation Concurrent Process, click Add and update the number of Hours after which you can send escalation email, and the recipients of each escalation email. For more information, see Configuring Delivery Plan . |
|
Permission to: |
Definition |
|---|---|
|
Design services and change data in this service group |
User can design services in this service group and change group data. These rights are typically reserved for the individuals who design and configure services in this service group. |
|
View services and other information in this service group |
User can view the service group and service definitions, but is unable to change them. |
|
Order services in this service group |
User can order services in this service group. This is how you allow service consumers to see and request these services. |
|
Assign rights to people |
User can assign these permissions to other people. This right is typically restricted to the service designer and owner of the service group. |
|
Create Services |
User can create new services in this service group. |
|
Maintain Services |
User can manage all services in this service group. |
|
Access Permitted Services |
User can access only the selected services on which he has permissions. |
Permission Changes for Service Groups on Upgrade to Prime Service Catalog 12.1
|
Pre Upgrade |
Upgrade to 12.1 |
|---|---|
|
User with Design Services and Assign Rights configured on an instance of service group |
|
|
Users with Design Service and Assign Rights configured for all instances of service group |
|
|
User with only Design Services on all Instances of service groups |
User is assigned Integration Administrator role |
Making Services Team Relevant
Marking the services or Service Groups as Team Relevant makes it easier for the user to order services for only those teams that have the permission to order those services. Depending on the services granted to the user (directly or inherited) you can allow the user to choose for which team the service is being ordered.
 Note | If Team Management is enabled but the ordered service is not team relevant, the service ordering will have no impact. |
If a service is marked team relevant, means that when ordering that service, it must be ordered for a specific team. The order form displays an additional field called Team Name. This field displays only those teams to which the user belongs and also has permission to order this service.
To set team relevant at service group level:
User must have service designer permission or Service Operation Administrator (SOA) role to set this option.
Creating a Service
Use this procedure to add a new service to the catalog and set the context for the service by including descriptive information, as well as to configure the important attributes and settings that affect reporting and display behavior of a service.
Before You Begin
Set up a service group. See Configuring a Service Group
| Step 1 | Choose . | ||
| Step 2 | Enter the
details in the fields provided.
| ||
| Step 3 | Click Add This Service. | ||
| Step 4 | After adding
the service, you can begin to configure it by entering information on the
General
tab.
The General tab is primarily used to influence the consumer experience as the end user browses the service catalog. Use the Service Attributes as a reference for completing the fields. | ||
| Step 5 | Click Save. |
Field
Definition
Name
The name
of the service. This is the name the end user will see in the service catalog.
The service name should not exceed 200 characters. For example: Computer Memory
Upgrade
Status
A status
of
Active means the service is searchable and available for
ordering in My Services. A status of
Inactive prevents the service from being searchable or
orderable within the service catalog. A service may be inactive if it is still
in draft form, has expired, or if it is a service you plan to offer at
intervals, but not always.
Service
Group
The
service group to which the service belongs.
Orderable
Service
A setting
that enables (Yes) or disables (No) the “Order” and “Order For Others” link for
the service in My Services.
Non
orderable services are typically created to provide customers with
nonactionable information in the service catalog.
Reportable
This
field does not affect the customer. It is for a service designer to specify
whether the service data should be loaded into the service Catalog data mart so
that it can be used in ad-hoc reports or queries constructed using Ad-Hoc
Reports and Report Designer in the Advanced Reporting module.
See the
Cisco Prime Service Catalog
Reporting Guide for additional information and best practices for
making services reportable.
Entitlement
Setting
this option to “Yes” allows any end user to request this service without
requiring an authorization. If a site level, department level, or service group
level authorization is in place, setting Entitlement to “Yes” ignores those
authorizations for this service.
Service ID
Displays
the internal ID of the service.
Compute
Price
This
field enables you to calculate the price of a service before the consumer
orders the service. If you select “Yes” in the drop down list, you see a
Compute
Price button when you choose to Order a Service in
My
Services.
Hide in
MyOrders
This field allows you to
hide the requisitions for this Service in the Orders page.
Ordering
Mode
This
field provides you an option to either add the service to a shopping cart or
order the service instantly. The options available are as follows:
Pagination View Mode
This
field allows you to present the dictionaries in the ordering page in the form
of a wizard in the Service Catalog module, showing form fields in multiple
pages with previous and next navigation controls. For more details on how to
configure the ordering page for a Service Item see,
Displaying Service Form as a Wizard.
Is
Template
Check the
Is
Template
check box, if you want to use the service as a template
Integrations.
Template
Type
This field
appears only when the
Is
Template option is checked. The Template Type field allows you to select
the template type when you create custom templates for UCSD or Cloud Center
services.
Hide In
Service Catalog
Select
this field to hide the service in Service Catalog module and the associated
requests for this service in Order Status and Completed Orders view in My
Stuff. This is useful if the Service Designer does not want these service
requests to be visible or cancellable by the end user. Often these are child
services that are invoked as part of a more complex service bundle.
Max
Quantity
This
option allows you to configure the maximum quantity of a service that can be
ordered in a single order. For more information, see
Configuring Maximum Quantity of a Service.
Team
Relevant
Check this
option to set the service as team relevant. For more information, see section
Making Services Team Relevant.
Description
A text
field for entering a succinct description of the product or service. This
information is displayed to the consumer in
My
Services or
Service
Catalog and should be as clear as possible so the end user knows exactly
what they are ordering.
Service
Level Description
This is
an optional text field. Anything entered here is displayed to the consumer in
My Services or Service Catalog and should be thought of as a promise to the
consumer about what level of service they should expect. The description may
not exceed 4000 characters.
Standard
Duration
The
Standard Duration is the standard (typical) delivery time for this service
after all authorizations and reviews have been completed. This information is
available to the customer before they request a service.
The
Standard Duration is not the due date for the service to be completed and is
not used to calculate due dates . This field does not take into
consideration the calendars of the service fulfillment team. It calculates
hours into days, and is used to calculate the Standard Compliance metric for
the service used in Advanced Reporting.
Display
Units
The
Standard Duration can be displayed in Hours or Business Days.
If you
choose to display by business days, the number of hours is converted to days
using the “Working Hours per Day” setting on the Plan tab.
For
example, if the standard duration for a service is 3 business days, you would
enter 24 hours in the Standard Duration field, assuming an 8-hour workday.
As you
compile and arrange your service delivery plan, the system keeps track of the
total number of hours required to complete all of the plan’s activities. It
also uses the “Working hours per day” setting (Plan tab > Tasks subtab; see
the
Fields
in Task Subtab) to compute how many working days are required to execute
the plan.
Forecasting Method
Choose
the method that will be used to forecast the service due date to the end user
in My Services after the service is submitted. This forecast should always be
considered approximate. No matter which forecasting method is chosen, Service
Catalog recalculates all due dates after all authorizations and reviews for the
request have been completed.
Choosing
a forecasting method has both functional implications (what the requestor of
the service will see, and when) and performance implications. See the
Forecasting Due Dates
for a detailed discussion.
Additional URL
The
Additional URL field can be used to further describe your service or link to
supporting information. For example, if the service is for desktop software,
you may want to include a link to an external product site so the end user can
read system requirements or ensure they are ordering the correct software.
The URL
must be fully qualified, beginning with “http://”. The service description will
include a “More Information ...” link, to access the specified URL.
Functional Positions
Available
functional positions and their corresponding personnel assignments for the
service. Functional positions are defined in Organization Designer. You can add
positions and assign people to the position, for this service.
For more
information, see Configuring Functional Positions , in
Cisco Prime Service Catalog
Administration and Operations Guide .
Keywords
The
search facility in My
Services returns services containing any word in the service name and
service description. Add additional keywords to help facilitate a user search.
For
example, if the service is “Order a New Laptop” and the user can choose either
a Dell or a Lenovo laptop, additional keywords might be: 'Dell' and 'Lenovo'.
These are
used for customer navigation only, and are not used in reporting. For more
information, see
Managing
Keywords.
Display
Categories
The
categories in which the service appears in
My
Services or
Service
Catalog. For more information, see
Categorizing Services.
Note
1-Click feature is available in Service Catalog module only.
Configuring Maximum Quantity of a Service
Max quantity functionality allows you to configure the maximum quantity of a service that can be ordered in a single order. You can configure Maximum quantity at Service level and Category level from the Service Designer module.
To set max quantity at service or category level, navigate to Service Designer > Services / Category > General and enter a value for Max Quantity. The Maximum Quantity field takes any value ranging from 0—999.
-
If max quantity is configured at service level and at category level, then service level max quantity value overrides the category level max quantity value.
-
If max quantity is configured at category level and for some of the services max quantity is configured at service level, then for those services alone service level max quantity will be considered.
-
If a service belongs to multiple categories and max quantity value is not defined at service level, the least max quantity value of all the categories will be considered.
-
If a service is bundled, the max quantity value of the parent service is applicable.
Unless you enable Allow Update Quantity option from the Administration > Settings My Services section, the max quantity configured in Service Designer is not effective.
The order submission nsAPI also uses max quantity to validate across applications i.e., cart, order management, Soap call, RAPI, and nsAPI.
Forecasting Due Dates
The methods for forecasting due dates are summarized in the table below and explained in detail in the following paragraphs.
|
Method |
Functionality |
Performance Implications |
|---|---|---|
|
Estimate Due Date from task durations |
The system forecasts the due date based on all tasks in the delivery plan, the anticipated duration for each task, and the assigned performer. |
All tasks (authorization/review and delivery) are instantiated, and individual queue or person calendars are consulted to determine scheduled task start and end times. |
|
Approximate Due Date using Standard Duration |
The system uses the calendar associated with the working hours of the Default Service Delivery queue to approximate due dates, rather than consulting the actual participant assigned to each task. |
All tasks (authorization/review and delivery) are instantiated, but individual queue or person calendars are not consulted. |
|
Do not forecast Due Date |
No due dates are forecast when the order is submitted. The user sees “TBD” as the Due Date in My Services. |
Only authorization/review tasks are instantiated when the request is submitted. |
There are both functional and performance implications in choosing the method for forecasting due dates. The following factors affect the accuracy of due dates forecast:
- Any authorizations or reviews associated with the service. Any initial forecast uses the specific duration associated with each of these authorizations. However, due dates are recomputed after all authorizations are completed. Variations in completion time for authorizations and reviews (typically, taking longer than specified in the delivery plan) can give an unrealistic forecast.
- Any conditional tasks included in the delivery plan. Since the conditional expression governing execution of the task can only be evaluated in the service delivery moment, any forecast cannot take conditional task execution into account. Therefore, the estimate may be inflated by included tasks that would actually not be executed. On the other hand, the estimate would always be a worst-case scenario (assuming execution of all tasks), so users could be pleasantly surprised if the service request is fulfilled sooner.
When due dates are forecast (either via Approximation or Estimate), Service Catalog must create (instantiate) all tasks in the delivery plan. This may take a significant amount of server processing time, depending on the number of tasks in the plan. Estimating the due dates will always take longer, since the work calendar assigned to each participant in the plan must be consulted to correctly derive the task start and end dates.
The Administration setting to “Submit, Approve, and Review Asynchronously” affects the perceived performance of Service Catalog when it comes to forecasting due dates. By default, this setting is off, so that “background processing of requisition submit” is disabled. Therefore, Service Catalog instantiates these tasks synchronously; that is, the user submits the order. Service Catalog creates the tasks as instructed in the forecast method, and then control of the page is returned to the user. For complex task plans, the user may wait a significant amount of time to proceed away from the order form.
If “Submit, Approve, Review Asynchronously” is set to on, Service Catalog creates tasks asynchronously; that is, in the background. Consequently, the user does not have to wait until all tasks have been created to exit from the order form and continue using Service Catalog. The wait time is eliminated. The difference in performance may not be obvious for requests with few (or no) authorizations or with simple delivery plans, but should be apparent for services with more complex workflows. After requisition submission, the status becomes “Ordered” until it is processed by the Business Engine. Afterwards, the status becomes “Ongoing”.
Because asynchronous processing requires additional configuration steps and it might not produce any perceived difference in performance for some installations, configuring Service Catalog to “Submit, Approve, and Review Asynchronously” is optional. Be sure to check with your system administrator to see if this setting has been enabled before deciding on a method for forecasting due dates.
Creating Custom Templates
Prime Service Catalog provides out-of-box templates using which you can then enhance it as per your requirement to create custom templates. These templates are non-orderable services which are used to generate CloudCenter application profiles services, Process Orchestrator (PO) Workflows, or UCSD services. The template defines the appearance of the orderable services created from these applications in Service Catalog module. These templates have the basic configurations required for the specific types of UCSD services, CloudCenter application profiles services, or PO workflows.
|
Application name |
Service Group |
Template |
|---|---|---|
|
UCSD |
Reserved Services |
|
|
CloudCenter |
CloudCenter Reserved Services |
Application |
|
Process Orchestrator |
Process Orchestrator Reserved Services |
PO Workflow |
You must track and map the newly created custom templates appropriately.
For more information on mapping these templates see sections Mapping the Custom Templates for UCSD Services, Mapping Custom Application Templates for Process Orchestrator , and Mapping Custom Application Templates for CloudCenter in Cisco Prime Service Catalog Administration and Operation Guide.
To create custom templates:
| Step 1 | Go to Service Designer > Services. |
| Step 2 | From the
respective service group which contains the out-box-templates, select the
required template which will act as a base for the custom template.
For information see the above table. |
| Step 3 | In the General tab, click Clone to clone the base template. |
| Step 4 | Optionally, enter a new service name and select the group to which the service must belong. |
| Step 5 | Uncheck the Reserved Form to retain the basic configuration settings of the template. |
| Step 6 | Optionally, you can enhance the presentation of the template. For information see Formatting Service Presentation . |
| Step 7 | Add new forms from the Form tab. |
| Step 8 | Additional task can de added such as Email Notifications. |
| Step 9 | Click Save to create the custom template. |
Note | It is recommended not to modify the entities which are part of the basic configuration. |
Configuring Bundles of Related Services
A bundled service is a service that contains one or more related services that are automatically ordered when a customer orders the bundle (parent). Bundling is a convenient way to group services that are commonly ordered at the same time. For example, all new employees might require the following services:
- LAN ID
- Desktop or Laptop PC
- New Phone with Voicemail
You could create a bundle that contains each of these services, rather than expecting users to remember to order all three services for a new employee.
In a bundle, the new service containing two or more related/existing services is referred to as the parent service . The services contained by a parent service are referred to as child services .
Work flows for Bundling Services
Creating and processing a bundle involves several different modules and tasks within Service Catalog. Here's a brief overview.
- Create: After creating service groups and services, use the Service Designer module to create a bundle.
- Order: A bundle can be ordered from the Service Catalog module. The users may not realize that a service is a bundle. For example, if they click the Order link when choosing the service from the services catalog, the composite order form for the bundle appears, and if they review the order form, only the parent service appears. However, if a user clicks the service-name link as it appears in the service catalog, they can then click links for each of the child services and see detailed information. They cannot however, order any of the child services individually this way. After an order is submitted, the Service Order Confirmation page lists all services included in the bundle. If an order for bundle has to be canceled, the complete order must be canceled; as the individual child services included with the bundle cannot be canceled.
- Schedule: Service Catalog treats the order like
any other set of requisition entries on a requisition: It schedules
- Authorization and review steps defined for the parent service, which override any authorizations defined for the child services.
- Delivery plan tasks for each of the services.
- Plan-monitoring tasks for each of the services.
- Deliver: The delivery plan of each child service executes as if the child service had been ordered on its own. The scheduling of the delivery-plan tasks for the child service depends, however, on the position of the included task for the child service within the delivery plan of the parent service. For example, if the parent service lists the child services of LAN ID, Desktop, and New Phone, then the tasks would be completed in that order. (This assumes that you chose to complete top-level tasks sequentially in the Delivery Plan. If you want the delivery plans for the child services to execute concurrently, you could change this setting.)
- Monitor: If Service Manager users monitor a plan, they can see the plan-monitoring task for any service on the Plan tab, in Service Manager. The plan-monitoring task for a parent service shows the included tasks for each of the child services. If the site configuration parameter “Show Task Link” (available in the “Personalize Your Site” folder in the Administration module) is set to On (its default), the tasks shown on the Plan tab are links to the actual task forms. For included tasks, these links take you to the plan-monitoring tasks of the included services.
The table below provides you the various tasks that you can do for a service bundle.
|
Tasks |
Procedure |
Description |
|---|---|---|
|
Create a Bundle |
To create a bundle:
The “Include Service” button becomes enabled. After you add a service to a bundle (making it a child service), Service Designer disables the two check boxes and instead displays a list of the bundles in which the service is included.
|
In Service Designer, begin by choosing the service you wish to use as the parent service or create a new service to act as the parent. Once you have chosen the service, click the Offer tab to get started. The assumption is that you have already created the child services that you wish to include in the bundle.
|
|
Associate other services with a Bundle |
To associate other services with a bundle:
Alternative method:
|
Prerequisites and Recommended Accessories allow service designers to associate additional services with the current service. These options may be specified both for bundled and nonbundled services.
If a service has prerequisites or recommended accessories, the corresponding link appears to the right of the service’s detailed description in My Services. There is no behavior associated with either the listed prerequisite services or accessories that must be ordered individually. These are optional but can be helpful to the end user. |
|
Prevent Bundling |
To prevent bundling a service:
|
If you want to prevent other service designers from including a service in a bundle, complete the following procedure. Services marked in this way do not appear in the “Select a service” dialog box when choosing child services. |
|
Change Order of Child Services |
To Change order of Child services:
|
If desired, you can make one of the subtasks conditional to effect an “opt-out” scenario. In this case, the child service still appears to have been ordered (with all tasks skipped). |
|
Change an Included Task Name |
To change an included task name:
|
|
|
Review Included Participants |
To review include participants in a bundle:
|
For each child service you add to a bundle, Service Designer automatically assigns participant information into the delivery plan of the parent service. The information on the Participants tab is taken from the Project Manager of the child service. Service Designer automatically assigns both the Performer and the Supervisor of the task using whatever is currently defined as the Project Manager of the child. If you change the Project Manager of the child service, the change is reflected dynamically for the included task. Service Designer names the performer of the included task the Subplan Manager. It names the supervisor the Plan Manager. |
|
Pricing Bundles |
|
The price of a Bundle includes the price of each included service, as defined in each child service. You set the price of any service on the Pricing subtab of the service's Offer tab. The price could potentially be adjusted by using the Set Price action in an active form component rule, applied either to the bundle as a whole or to its component services. For your convenience as you construct a bundled service, the price of each child service is listed on the parent service's Offer tab, Bundle subtab. If a child service’s price is defined as Pricing required, the system schedules a pricing step for that service at the time a My Services user orders the bundle. |
|
Discount Price of a Bundle |
To discount a bundle:
|
The price of a bundle can be discounted in either of two ways:
For example, if the cost of all child services adds up to $5,000 and you enter a negative price of $1000 for the parent service, the net cost for the bundle becomes $4000. By doing this, you encourage the end user to order the bundled service rather than each service individually. Customers can see that the price has been discounted only after they've clicked Order for the bundle. To let them know about the discount up front, you can use the service's Description field on the General tab, or the Description field on the Offer tab/Pricing subtab, to briefly highlight the financial advantage of choosing the bundled service. |
|
Control Display Parameters on the Order Form |
Choose Administration > Home > Personallize your Site> Customizations > Service Manager > Show Bundle Data |
When the system creates the composite order form for a bundled service, any duplicate dictionaries are eliminated. This means that if a dictionary is associated with a parent service and one of the parent's child services (or multiple child services), the system will display only the first instance of that dictionary on the bundled service order form. There are two options to display service form data:
|
|
Review Included Tasks |
To review included tasks in a bundle:
The child services are automatically named following this convention: “Deliver Included Service service-name .” For example, a service might appear as “ Deliver Included Service Phones.” |
For each service you add to a bundle, Service Designer automatically inserts a task into the delivery plan of the parent service. This task is referred to as an included task. Included service tasks behave like most delivery-plan tasks, with the following exceptions:
Although the task is automatically named “Deliver Included Service service-nam e,” you can change the task name if desired. You can also arrange included tasks in a task/subtask relationship by indenting one under another. However, the delivery of both services will start at the same time. |
|
Restricting Cancellation of Child Services in a Bundle |
To ensure that the customer cannot cancel the service after a task in the service bundle has started
|
A customer can cancel a bundle once it has been ordered. Canceling a bundle cancels all included services. The option to cancel individual child services is disabled for the end user on the Edit Requisition page. Service Designer essentially defines “the point of no return” for the customer to cancel a service. This option can be checked for the entire bundle of service or for individual subtasks within. However, once this point has been reached for any of the services within the bundle, the customer cannot cancel the bundle. The “Do not allow cancellation of service after task starts” check box on the service's Plan tab, General subtab in Service Designer essentially defines “the point of no return” for the customer to cancel a service. This option can be checked for the entire bundle or for individual child services within, but once this point has been reached for any of the services within the bundle, the customer cannot cancel the bundle. Additionally, when “the point of no return” has been reached for any service or subtask within the bundle, the Cancel button is removed for the service order. |
Note | For namespace usage, see Namespaces. |
Customer View of Bundles
To order a bundle in Service Catalog, click the service name to view the service details and then click “Included Services” on the Details page to see all services included in the bundle.
Click on each service name to view the specific details related to that service. At this level, a Return to Service Bundle button displays in place of the Order Service button, which means a child service cannot be ordered from within a bundle unless the entire bundle is ordered. To order services separately, the return to the service catalog.
When ordering a bundle, the Order Confirmation page displays the names of all services in the bundle including the Due Date for each child service.
The Track Resolution page displays a list of all child services in the bundle. Click the link to view the order form and to view the Delivery Process for each service as it is performed.
Defining Service Level Permissions
The Permissions tab shows which users are allowed to order this service, view the services, or modify services.
You can grant the following types of permission:
-
Order Service: Allows the user to order this service.
-
Read: Allows the user to view the service.
-
Read/Write: Allows to view or modify the service.
To grant permission on a service:
Granting access to “Anyone” allows any Service Catalog user to order this service. Only services that are truly universal in nature, and open to the entire customer base, should have Anyone as a grantee. The “Site Administrator” role, by definition, has permission to order any service.
Feedback