Service catalogs allow creating an ordered structure of internal and external services provided to consumers. Generally, at least one service catalog is included in the Self-Service Portal delivery. Customize it and offer your customers the most actual products. Provide a way to raise incidents and requests in an enterprise-wide standardized way.
Service Catalog architecture implements Record Extended Model principles allowing customizing categories and request templates with minimal effort.
The scheme below illustrates service catalog working principles.
| Element | Description |
|---|---|
| Catalog | A high-level entity uniting all other items such as categories and request models. Catalogs allow facilitating self-service operations for end-users. |
| Category | Element group joined with some common attribute. |
| Request Model | A template used to raise requests and other task objects. It can be extended with Record Extended Model functionality. |
To configure a service catalog, follow a simple procedure:
- Create a service service catalog itself.
- Create service catalog categories.
- Create catalog request models.
- Extend request models with record attributes.
- Make adjustments into portal configuration (create and configure portal nodes).
All these steps are described below.
Creating service catalogs
Service catalog record is the highest-level entity aggregating all other items below (categories, subcategories, items).
To support multiple service catalogs displayed within one service portal instance, it is necessary to configure dedicated node for every catalog. These nodes should define displayed link to this catalog in the portal header, also in the service catalog card in the portal main area.
Otherwise, the service catalog created will be not displayed on the service portal and will be accessible only via direct link.
Role required: catalog_admin, admin.
To create a new service catalog, complete the steps below:
- Navigate to Request Model Catalog → Catalogs.
- Create New and fill in the fields.
- Click Save or Save and Exit to apply changes.
Service catalog form fields
| Field | Mandatory | Description |
|---|---|---|
| Name | Y | Service catalog name. |
| Description | N | Service catalog description. |
| Managers | N | Specify users authorized to make any changes to the catalogs configuration. You can select more than one user in this field. Users responsible for specified catalog management should be granted with the catalog_manager role. |
| Available for Use | N | Select this checkbox to make this service catalog displayed on the portal. |
Creating catalog categories
Catalog category is an entity allowing to contain request models of a similar theme together, like a folder in a filesystem. For example, you can create category "IT Assistance", and after that, create models for request like "New Laptop Request", "Equipment replacement" in this category. So, this category will be a container for these request models.
Categories hierarchy can be multi-level, so you can create really extensive structure by setting up category relationships ("parent" and "child").
To create a catalog category, complete the steps below:
- Navigate to a catalog record for which you are going to create a category record.
- Scroll down to the Related Lists area and click New in the Categories tab.
- Fill in the fields, after that, click Save or Save and Exit to apply changes.
You can also create a catalog category from scratch. To do so, navigate to Request Model Catalog → Categories. The next steps are the same as described above.
Catalog category form field
| Field | Mandatory | Description |
|---|---|---|
| Name | Y | Specify a category name. |
| Description | N | Specify a category description. |
| Order | N | Specify a number indicating a category order. Categories are sorted in ascending order. |
| Catalog | Y | This field should be populated with the reference to the catalog record to which this category belongs. If the category is created out of some catalog, then this field is populated automatically. |
| Parent category | N | If you have implemented a category hierarchy, then specify a parent category for the current category. If not specified, then this category is of the highest level. |
| Image | N | Upload an image to be displayed on the category tile on the Self-Service Portal. |
| Available for Use | N | Select this checkbox to make this category displayed on the portal. |
Note that a category is not displayed within the service catalog in the cases below:
- Category is empty (it does not contain any items or subcategories).
- The user does not match User Criteria to access the category, subcategories, or request models in it.
- If all items in the category are not available for the user, the category is not displayed either.
Creating request models
Request models are templates basing on which a new request object can be created. Request models can be extended with the Record Extended Model functionality.
To create a request model, complete the steps below:
- Navigate to a category record for which you are going to create a request model.
- Scroll down to the Related Lists area and click New in the Request Models tab.
- Fill in the fields, after that, click Save or Save and Exit to apply changes.
You also can create a catalog category from scratch. To do so, navigate to Request Model Catalog → Request Models. The next steps are the same as described above.
Request model form field
| Field | Mandatory | Description |
|---|---|---|
| Name | Y | Request model name. |
| Description | N | Request model description. |
| Order | N | Specify a number indicating a request model order. These items are sorted in ascending order. |
| Table | Y | Specify a table to register incoming requests in it. It can be, for example, the Task table or other tables extending it. |
| Category | Y | This field should be populated with the reference to the category to which this request model belongs. If it is created out of some category, then this field is populated automatically. |
| Post-Registration Action | N | Select what will happen after the request based on this model is submitted. Available options:
|
| URL | N | Specify URL to redirect after request submitting. This field appears if the Redirect on the selected page option was selected above. |
| Image | N | Upload an image to be displayed on the request tile on Self-Service Portal. |
| Available for Use | N | Select this checkbox to make requests based on this model displayed on the portal. |
| Service | N | Specify a service for which this request model is intended for. It can be useful for service-based segregation within one Service Catalog (one request form for the Email service, another one for the Website service, and so on). |
Extending request models with record attributes
Basically, request models contain limited attribute set predefined. You may need to extend it relying on the task you need to handle.
For example, you need to add a Comment field to the model so that it should map to the Additional Comments field in the record.
To do so, complete the steps below:
- Navigate to a request model record which you are going to extend with an attribute.
- Scroll down to the Related Lists area and click New in the Attributes tab.
- Fill in the fields, after that, click Save or Save and Exit to apply changes.
Record attribute form fields
| Field | Mandatory | Description |
|---|---|---|
| Container | Y | Reference to the previously created request model. If you are creating an attribute out of a request model, this field is populated automatically. |
| Column type | Y | Specify a column type for this attribute. |
| Title | Y | An attribute title. Can be specified in a language other than English. Latin, Cyrillic letters, [0..9] numbers and the underscore symbol ( _ ) are allowed. |
| Column Name | Y | A column system name. Latin letters, [0..9] numbers and the underscore symbol ( _ ) are allowed. |
| Map to Column | N | Specify the target field to map the attribute value after the record is created. This option allows nimble transferring of the attribute values to fields. Note that if the target field is mandatory, then the value is saved before it is processed by server validation engine. Also, if the target field is mandatory, it should be not displayed on the form, otherwise the client validation engine may hamper the record saving. |
| Comments | N | Put here some comments describing your attribute. |
| Active | Select this checkbox to make the attribute active or inactive. | |
| Read Only | Select this checkbox to make the field adding by this attribute read-only. | |
| Mandatory | Select this checkbox to make the field adding by this attribute mandatory. | |
| Type Specification tab | ||
| Max Length | N | (For the columns of the String or Text type) Specify a value max length of this column. The value length cannot exceed allowed length for the specified data type. |
| Default Value tab | ||
| Default Value | N | Specify a default value that will be populated to the field when creating a new record. This field may be specified by a JavaScript scenario as well. |
| Use Dynamic Default | N | Select this checkbox if you want to generate the default value dynamically. |
| Dynamic Default | Y | This field appears only when the Use Dynamic Default attribute is selected. Select the script from the Dynamic Default Values (sys_default_value_dynamic) dictionary, so its execution result will be automatically calculated and entered into this field; this value will be the default value for the column specified.
|
Configuring portals
As mentioned above, you can implement more than one service catalog within your company infrastructure. To bind these catalogs within your Self-Service Portal, note the following: every single catalog requires dedicated portal node to set up and configure.
For your convenience, a preconfigured portal node containing all necessary settings is included into platform delivery. You can use it as a sample for your customized nodes.
Portal node configuration
| Field | Description | Out-of-the-Box value |
|---|---|---|
| Portal | Specify the portal for which this node is created. | Self-Service Portal |
| Page ID | Specify a portal page containing catalog template. | Service Catalog (Path Name: sc) |
| Item Table | Specify a table containing catalog items. | Request Model |
| Item Parent Column | Specify the column in the table defined above containing information about which category is parent for items. | Category |
| Category Table | Specify the table containing catalog categories. | Category |
| Category Parent Column | Specify the column in the category table defined above containing information about which category is the parent for others. | Parent Category |
| Category Item Condition | Specify a condition that must be met to display a catalog category item. | Available for Use is Yes AND Order ascending |
| Category Condition | Specify a condition that must be met to display a catalog category. You can use a specified category in more that one catalog instance. To implement this, use the is one of operator instead of is. Then you'll be able to specify several catalogs to display a category. Keep in mind that every catalog instance should have dedicated portal node as described in this section. Example: Catalog is one of Moscow Users, London Users | Catalog is Service Catalog AND Available for Use is Yes AND Order ascending |
| Item Page | Specify a portal page containing a template for the catalog request. | Service Catalog Element Page |
Configuring catalogs multiplicity
As mentioned above, it is necessary to configure a dedicated node for every catalog. To do so, complete the steps below:
- Navigate to Tree Structures → Nodes.
- Click New and fill in the fields.
- Click Save and Save and Exit to apply changes.
See the screenshot below as the form filling example.
Node fields
| Field | Mandatory | Description |
|---|---|---|
| Title | Y | Node title. This field can be populated in any language supported by the platform. In our example, you can specify the Service Catalog title. |
| Active | By selecting this checkbox, you can make a node active or inactive. | |
| Tree | Y | Select a previously created tree containing information about the structure. To display the catalog in the portal header, select the Portal Header Menu tree included. |
| General tab fields | ||
| Access Criteria | N | Specify the User Criteria defining user access to this node (card or header element). If no criteria selected, then all users are allowed to use this element and its sub-elements as long as they are not protected by separate criteria. |
| Node Type | N | Specify a node type by choosing from the previously created. |
| Nesting Level | Y | Node nesting level. This field is populated automatically. This parameter shows on which nesting level this item is located. |
Extra attributes tab | ||
| This tab appears if the used node type has the RE model specified, and the Need URL attribute of the node type is enabled. | ||
| URL | Y | Specify an URL for an item. In this field, you can specify either absolute or relative URL (relative to the current portal referring to the tree to which the current node is assigned): Absolute URL: https://instance.example.com/portal/profile Relative URL: /profile |
| Icon | N | Specify the icon for an item by attaching it from your device.
|
| Short Description | N | Specify a short description for the item. |
Access control
You can configure access (allow or deny) either to catalog category or to catalog request model using the User Criteria engine. So you can vary catalog items displaying to the audience by defining flexible conditions.
How it works
Administrator defines access as described below to catalog elements (categories and request models) by allowing or denying access to some audience segments. To segregate segments amongst themselves, user criteria are used.
After that, when a user navigates to a service catalog, it is processed by the User Criteria engine against the pattern below to make a decision, if this user allowed or denied to display specified catalog elements.
Configure category access
To configure category access, complete the steps below:
- Navigate to the category you need to configure.
- Scroll down to the Related Lists area and click on the User Criteria tab.
- Click New and fill in the fields.
- Click Save or Save and Exit to apply changes.
You can also create a category access configuring record from scratch. To do so, complete the steps below:
- Navigate to Request Model Catalog → Category User Criteria.
- Click New and fill in the fields.
- Click Save or Save and Exit to apply changes.
| Field | Mandatory | Description |
|---|---|---|
| Category | Y | Specify category to which you need to configure access |
| Criterion | Y | Specify User Criteria to match. |
| For Users by this Criterion | Specify the access option. Available options:
|
Configure request model access
To configure request model access, complete the steps below:
- Navigate to the request model you need to configure access.
- Scroll down to the Related Lists area and click on the User Criteria tab.
- Click New and fill in the fields.
- Click Save or Save and Exit to apply changes.
You can also create a request model access configuring record from scratch. To do so, complete the steps below:
- Navigate to Request Model Catalog → Request Model User Criteria.
- Click New and fill in the fields.
- Click Save or Save and Exit to apply changes.
| Field | Mandatory | Description |
|---|---|---|
| Request Model | Y | Specify request model to which you need to configure access. |
| Criterion | Y | Specify User Criteria to match. |
| For Users by this Criterion | Specify the access option. Available options:
|
When a user has no access to create a record with a particular model, the following message appears:
You have no permission to create a record with the selected request model
To enable access to the request model for this user, they should match the User Criteria set for this model.
