Share via

Building CCF Workflows

  • Article

A workflow is a series of steps in a business process. In CCF, each step in a workflow has an associated hosted application. There are two types of workflows: forced workflows and non-forced workflows. In a forced workflow, the agent must complete the steps sequentially. In a non-forced workflow, the agent can perform the steps in any order.

You can use the Admin Console to configure the steps and access the permissions for a workflow. To use the Admin Console to configure workflows, refer to the CCF 2009 SP1 Deployment Guide.

In a workflow, applications can be designated as global or non-global. In the Application table initialization string, the <global/> tag specifies that the application is global. If the application does not have this tag, the application is non-global.

In the Application table initialization string, the <workflow/> tag specifies that the application is only visible when a workflow requires it. The tag indicates that the application is dependent on the workflow. Applications without the <workflow/> tag are always visible and are independent of the workflow. This rule applies to both global and non-global applications.

For applications that are part of a workflow, the workflow drives the application; the application does not drive the workflow. For example, during a workflow, if an agent uses tabs or the Session Explorer to select an item or activity, the item or activity is not marked as completed (even if it actually is completed) until the workflow is done. This happens even if the selected item is not part of the workflow. If the item was marked as completed, the agent would need to take extra steps to select the next workflow activity, and the workflow would slow down the agent.

Note

A workflow applies to a session with a customer only if that customer has a customer ID. If a workflow is applied to a customer who does not have a customer ID, the workflow activities will not function until an ID is assigned.

The CCF implementation of human workflow uses the Windows Workflow Foundation (WF). A step in a workflow is represented as an activity called CcfWorkflowStep. The CcfWorkflowStep activity defines the step as focusing on the specified hosted application. If there is an action configured for the application, it is executed.

A workflow starts when a user clicks a workflow step of the hosted workflow control. Next, a FireRequestAction() method calls to the CustomerWorkflowManager with a human workflow action and parameters describing the hosted application (the hosted application corresponds to the step that the user clicked). The CustomerWorkflowManager then handles the action including hooking into and setting up the CcfWorkflowStep.

A workflow engine manages the series of steps in a workflow. It provides the UI and the functions that can be performed in the workflow, such as start, finish, next, previous, and cancel.

You can enable a workflow engine by setting the WorkflowExists switch in the Options table of the CCFInfrastructure database. You can also use the Admin Console to configure WorkflowExists. To configure WorkflowExists in the Admin Console, find the Settings node, and then open the GeneralSettings node.

The following flowchart illustrates a typical workflow use case for global applications.

Dd632139.787e75bb-cfd9-439d-9124-649b80ec9942(en-us,MSDN.10).png

The agent logs on to the system and starts the ID.

If there is a workflow (that is, if a workflow engine is running), only global, hosted applications that the agent is permitted to use and that are independent of the workflow will be loaded and displayed.

If there is not a workflow, all global applications are loaded and displayed, regardless of whether they are part of a workflow.

The following flowchart illustrates a typical workflow use case for non-global applications.

Dd632139.ce909d98-020e-4f45-8b8c-8a6fae4e67e8(en-us,MSDN.10).png

The agent starts a work session. When the session starts, if there is a workflow (that is, if a workflow engine is running), then all non-global, hosted applications that the agent is permitted to use and that are independent of the workflow will be loaded and made visible, in addition to those already loaded in case 1.

If there is not a workflow, all non-global hosted applications that the agent is permitted to use will be loaded and made visible, in addition to those already loaded in use case 1.

The following flowchart illustrates a typical workflow use case where the agent selects and starts a workflow.

Dd632139.7ba12a6a-45d5-4341-badf-0d0a2d27954e(en-us,MSDN.10).png

When an agent selects and starts a workflow, all global and non-global applications that are dependent on the workflow are loaded and made visible, in addition to those already loaded in Use Case 1 and Use Case 2.

The following flowchart illustrates a typical workflow use case where the agent finishes the workflow.

Dd632139.718bd45a-3b1f-4fbe-811f-da63728133b6(en-us,MSDN.10).png

When an agent completes a workflow and clicks Done, regardless of whether the workflow is forced or non-forced, all global and non-global applications that are dependent on the workflow are closed and removed from the Session Explorer. Non-global applications that are independent of the workflow are still visible and are only closed when the session is closed. Global applications that are independent of the workflow are still visible and are only closed when the ID is closed.

If an agent clicks Done before he or she finishes the workflow, one of the following events occurs:

  • If the workflow is forced, the following message appears: “Please complete all steps to finish the workflow.”
  • If the workflow is not forced, all global and non-global applications that are dependent on the workflow are closed and removed from the Session Explorer. Non-global applications that are independent of the workflow are still visible and are only closed when the session is closed. Global applications that are independent of the workflow are still visible and are only closed when the ID is closed.

The following flowchart illustrates a typical workflow use case where the agent cancels the workflow.

Dd632139.1250975c-34e6-4cf5-9e24-0d343b291d96(en-us,MSDN.10).png

When an agent cancels a workflow, all global and non-global applications that are dependent on the workflow are closed and removed from the Session Explorer. Non-global applications that are independent of the workflow are still visible and are only closed when the session is closed. Global applications that are independent of the workflow are still visible and are only closed when the ID is closed.

The following flowchart illustrates a typical workflow use case where the agent closes the session.

Dd632139.f9fdc933-ea1d-4995-bf2d-b44e1b7bb09c(en-us,MSDN.10).png

When a session is closed, if there is a workflow (that is, a workflow engine is running) then one of the following occurs:

  • If the workflow is forced, the following message appears: “You have to complete workflow steps before closing session.”
  • If the workflow is not forced, only the tagged global applications and all of the non-global (tagged and untagged) applications are closed.

If there is no workflow, only the non-global applications, whether they are tagged or untagged, are closed. All of the global applications, tagged and untagged, are visible until the ID is closed.

For detailed information about creating workflows with the CCF software factories, see the HAT Software Factory, Advanced MCE Development, and Extending DCS Functionality.