The Service Catalog is a fully configurable means of presenting the services, apps, and information available to the business, in a highly graphical manner. All types of content can be mixed and matched to present a richer offering to employees with diverse needs, ranging across the organization.
An App Store allows a library of image-rich available applications to be offered so that business users can make their own sourcing decisions. This allows IT to retain control without limiting the decision-making abilities of the business users. Configurable filters can be defined to enable easier discovery and delivery can be determined by individual apps, whether immediately downloadable or requested for subsequent delivery through a range of integration options.
A panel allows real-time HTML content from an external source to be presented. This might be the logged-on user’s open tickets, division reports, or even a news feed. It is also possible to present clickable buttons within the panel which could auto-create a context-appropriate request; for example, add extra memory to a specific VM from a list of available VMs.
A service-driven category can be configured with HTML-embedded images and links to aid navigation and service discovery. Categories can contain any number of sub-categories or services, allowing the user to be taken directly to an endpoint, or also providing backup information on the service offering.
This article covers the following topics:
- Configuring Category Hierarchies
- Defining an App Store
- Defining a Panel
- Defining a Service
- Configuring a Request Type
- Configuring a Bundle
- Suppliers and Catalog Items
Configuring Category Hierarchies
The Service Catalog provides the configurable hierarchy of categories within which your services, items, and informational panels can be displayed. In addition to the standard category type, also available are ‘App Store’ and ‘Panel’, which are suitable to display an inline HTML element.
Category descriptions can be configured as HTML with embedded images and links to aid navigation and service discovery. Standard categories can contain any number of sub-categories or services, and access restrictions can be applied at any category or Service within the catalog to ensure that users only see what is relevant to them. If good quality images are available for the associated services, consider using a tiled view for a modern look.
The Service Catalog administration pages allow WYSIWYG (‘what you see is what you get’) editing of the hierarchy and allows moving/copying of category nodes as well as the linkage of services and items. All elements of the Service Catalog can be imported/exported via an XML file, for more flexible maintenance across systems.
Service Catalog content can be presented in a scrolling carousel or a menu alongside standard category sections. Categories have a number of display style options, including large and small tiled icons.
Access restrictions can be applied to any category or service within the catalog to ensure that users only see what is relevant to them. If an end-user has access to only one ‘category’ within the Service Catalog, they will see that category fully expanded on the home page.
Defining an App Store
Items can be added to one or more App Stores. Catalog items are displayed as ‘tiles’, which showcases the associated image, and is an important part of the presentation to the user; however, a default image will be displayed if no image is provided. A short item description is displayed below the tile, as well as a price (or ‘free’), rating stars (if available), and a configurable item attribute; for example, ‘operating system’. Clicking a specific item will open a popup containing further details, including an extended description, multiple screenshots, attribute information, and an area for a user to rate and review the item, as well as viewing others’ ratings and usage.
Multiple appropriate filters can be defined against an app store to ensure the user can easily find or assess the merits or suitability of the apps offered. The search facility, a combination of free text search and filters, further enhances user discovery.
The action associated with an app can be set to either immediately download from a specified product URL, open a link in a new window, or request in the usual way. The button text can also be changed for a product as well as some on-screen help text added. These properties can also be overridden by an external hook, triggered when the requester views the app details.
Defining a Panel
Another category type allows a panel to be created, displaying HTML information from an external source within the panel; a click-through option allows data to be displayed full page. A number of properties are available to allow displayed information to be both secure and appropriate to the user.
The panel can also be extended to enable a button click to generate a specifically targeted request, pre- opulated with appropriate data; for example, allocate more memory to one of a list of VMs.
More complex integration options may require developer resources to achieve the best results. Please visit Support at https://frontofficehelp.biomni.com/hc/en-us/requests/new for more information or to request assistance.
Defining a Service
Services are presented to users within the Service Catalog via a configurable hierarchy. Each service can be defined to contain a variety of information to ensure users fully understand the service offering, its pricing, and service levels. A service can be configured with a number of standard actions, allowing it to be requested by users where appropriate.1
A Request Type defines a request form for the capture of options and preferences by the requestor, rules for determining how a request is approved, and additional attributes that control its security and lifecycle. Request Types can optionally contain line items assigned to them from either a pre-configured bundle (package) or freely assigned items selected from product catalogs by the requestor.
New services can either be created or imported via the Service link on the main Administration page. When a service is created or imported it always starts with a primary status of “Draft”. Whilst the service is at the Draft status an additional sub status can be assigned to denote its specific stage in development. Draft services are not visible by users and can therefore be changed multiple times without impacting what they see. When ready to publish the service, select Make Live, and the service will appear in all the categories linked. Once live, the only changes that can be made to a service is to change its category linkage. A new Draft version of a Live service can be taken, leaving the Live one visible and unchanged to users. When ready to replace the Live version of the Service, select Make Live again; this will automatically replace the existing live version.
Configuring the Action tab of a service allows control of whether users can request the service or not. For requestable services, there are a number of action options available, the most widely used being the linkage of a Request Type.
1 Submission of request subject to license
Configuring a Request Type1
Request Types are designed to provide a method of capturing the information necessary to fulfill a user’s request for services. Request Types can contain line items where applicable, either from a pre-determined bundle/group of items or individual items selected by the user from the available catalogs. The benefits of designing a request type:
- Ensure that the right information is gathered on the request form within fields created from a wide range of field types.
- Control how these fields are displayed to the user using form sections and column layouts.
- Determine approval routing dependent on who is raising the request and the contents of the request.
- Control who can see and/or edit parts of the request throughout its lifecycle.
Any number of request types can be designed, created, and linked to actionable services.
1 Submission of request subject to license
Configuring a Bundle
A bundle is a collection of items from one or more product catalogs, grouped for easy selection. The contents can be fixed or marked as optional for the requestor when placing a request.
Each Bundle is given a name and a description, which can be configured with HTML or images as required. It is important to use a high-quality image for associated items, for maximum impact to aid selection. Bundles can be linked to specific Request Types ensuring that when selected the relevant request forms and approval routing rules are assigned.
Suppliers and Catalog Items
Product catalogs provide a means of presenting users with choices of options within service requests and allow authorized users to raise purchase requests within Front Office. Both internal and external supplier catalogs can be managed and presented in Front Office, either in their full searchable/browsable format via the full catalog view or embedded within pre-packaged bundles. A catalog must be associated with a supplier and can be imported into Front Office via the administration pages.
Share this article