Reusing client-side human services

To break down a client-side human service into meaningful subflows that can be separately managed and reused in different contexts, you can define the reusable subflows as nested client-side human services.

About this task

You can reuse the nested services in other client-side human services, which can be either top-level, root client-side human services or other nested client-side human services. Root services can contain one or more single- or multi-layered nested services.

When you build the service logic for your tasks or instance user interfaces in the designer, you might want to reuse common steps that are defined in other client-side human services. For example, creating an insurance claim might include a common set of steps. If you define the steps in a nested client-side human service, you can reuse them in other client-side human services. At run time, the nested client-side human service or services run as part of the parent root service.

When you create a client-side human service, you can specify whether it can be used as a nested service or as a root service. You can revisit the selection that you made in the Overview properties.

Before you create a nested client-side human service, understand the following concepts.
Usage settings
The usage settings of a root client-side human service depend on its intended purpose, and you can specify them in the Overview properties. The Use as setting is disabled for nested services because the configuration of a nested service is tailored for reuse. To ensure that the behavior of the root service is consistent at run time, in the nested service use elements that are compatible with the specified usage type of the root service.
Variable scope
In a hierarchy of nested client-side human services, variables are defined in isolation and are not automatically shared between the parent client-side human services and their nested services. To pass variables between a parent client-side human service and its nested services, you must set the data mapping. For more information, see Data mapping for nested client-side human services.
For input and private variables that you define for either root or nested client-side human services, you can specify default values that take effect at run time. For the default values, you can specify both simple and complex values, as well as arrays for lists. Optionally, if you have environment variables or exposed process values (EPVs) that you want to use in your client-side human service, link them to the client-side human service in the Variables view. See Declaring variables.
Stay-on-page behavior
When you use a stay-on-page event in a nested client-side human service, based on the logic that you defined, the stay-on-page behavior can loop the service diagram back to the last displayed page, which can be either in the same service as the stay-on-page event or in an ancestor client-side human service.
Error handling
Error event handlers that are defined in a hierarchy of nested client-side human services are not visible to all the services in the hierarchy. An error event handler that is defined in a nested client-side human service catches errors from the service in which it is defined and from all the nested services below it.
When an error end event is used in an error event handler in a nested client-side human service, it ends the flow of the nested service, but the execution of the parent service continues. If the client-side human service is used in a root process, the error end event propagates the error data all the way to the process. An error intermediate event that is set up at the process level can catch the error that is thrown by the error end event that is defined at the human service level.
For more information about error handling in client-side human services, see Handling errors in client-side human services.
Data change handling
When client-side human services contain one or more nested client-side human services, only the root-level data change event handler is used. If the data change event handler in a nested service is bound to any views, you can redirect those bindings to the root data change event handler by selecting Trigger the root data change event handler in the Implementation properties of the nested service activity.
In the Behavior properties, all the page boundary events in the current client-side human service that can trigger the root data change event handler are shown. If there are nested services that have Trigger the root data change event handler selected, they are also shown in the Behavior list.
Using the data change properties of a page, you can perform client-side validation of the page contents or control a button enablement through a conditional variable. To do that, you can add a fast-executing client-side JavaScript that has validation script logic that reacts to data changes in the page. For more information about data change handling in client-side human services, see Validating coach data without exiting a coach.

The following procedure describes how to nest a reusable client-side human service in another client-side human service. A step-by-step example is also provided.

Procedure

To nest a reusable client-side human service in another client-side human service:

  1. Open the workflow automation that contains the root client-side human service.
  2. Build the nested client-side human service that contains the common steps that you want to reuse. See Building a client-side human service.
    In the creation wizard, select Use as a nested service to ensure that the client-side human service that you are building is configured for reuse. To specify that you want to use the new service on multiple device types, select Intended for use on multiple devices.
    After the service is configured as a nested service, its name becomes available to select in step 6.
  3. Open the root client-side human service that you want to work with.
  4. In the Diagram view, add the nested client-side human service Nested client-side human service tool and wire it as required in the root service diagram.
  5. In the Implementation properties of the nested service node, under Behavior, specify the client-side human service to be nested. Click Select to select an existing client-side human service, or click New to create one. See Building a client-side human service.
    Restriction: To avoid unexpected behavior at run time, do not use a circular nesting pattern when you model your client-side human services. For example, if your model includes a client-side human service A that nests a client-side human service B, do not configure B to circle back and nest A.
  6. In the diagram, double-click the nested service node to open the service and edit it as needed.
  7. Optional: In the diagram of the root service, use the Data Mapping options to initialize the variables in the nested service. See Data mapping for nested client-side human services.
  8. Click Save or Finish Editing.