Cisco Context Service is a cloud-based omnichannel solution for Cisco Unified Contact Center Express. It enables you to capture your customer’s interaction history by providing flexible storage of customer-interaction data across any channel.

Context Service works out of the box with Cisco Customer Collaboration products. Context Service also provides an SDK interface for integration with your own applications or third-party applications to capture end-to-end customer-interaction data.

For more information about Context Service and to check service availability, see https://help.webex.com/community/context-service.

You can manipulate the call variables layout that an agent sees when a call is answered by using a workflow. To do so, configure an HTTP Request workflow action and set the value of the ECC variable user. Layout to the name of the custom layout to display.

For information about how and when workflows are executed, see Workflows and Workflow Actions.

For more details, see the section, "Adding an HTTP Request Workflow Action" in the white paper Cisco Finesse: How to Create a Screen-Pop Workflow.

The Finesse Layout XML defines the layout of the Finesse desktop, including tab names and the gadgets that appear on each tab.

Use the Manage Desktop Layout gadget to upload an XML layout file to define the layout of the Finesse desktop for agents and supervisors.

Actions on the Manage Desktop Layout gadget:

• Finesse Default Layout XML: Expands to show the layout XML for the default Finesse desktop.

• Restore Default Layout: Restores the Finesse desktop to the default layout.

• Save: Saves your configuration changes.

• Revert: Retrieves and applies the most recently saved desktop layout.

Important

After a system upgrade, the old desktop layout is retained. If you had a modified desktop layout before upgrade, perform the following steps to ensure you obtain the latest changes: Sign in to the Finesse administration console and click the Desktop Layout tab. Copy the desktop layout to a text file. On the Manage Desktop Layout gadget, click Restore Default Layout. Click Save. Using the text file of the desktop layout that you saved before the upgrade as a reference, modify the layout to include the changes that you made to the previous layout. Click Save to save your changes.

If any changes are made to the component IDs or URLs in the default XML layout, the following features may not work as expected.

Note	The components can be rearranged in any order to show on the Finesse desktop.

The Cisco Finesse default layout XML contains commented XML code for Web Chat and Email gadgets available for the Finesse desktop. Each gadget or tab is surrounded by comment characters (<!-- and -->) and comments that describe what the tab or gadget is for and how to add it to the desktop.

Note

The Chat and Email Control gadget is only supported at the page level. You must ensure that the Chat and Email Control gadget (<gadget>https://localhost/agentdesktop/gadgets/NonVoiceControl.xml</gadget>) is placed within the <page></page> tag. Placing this gadget within a <tab></tab> tag is not supported.

The procedure that you follow depends on your deployment. The following table describes when to use each procedure.

Note	After you add the Web Chat and Email gadgets, sign in to the Finesse desktop and make sure they appear the way you want. Agents who are signed in to Finesse when you change the desktop layout must sign out and sign back in to see the change on their desktops.

Cisco Unified Intelligence Center provides Live Data real-time reports that you can add to the Finesse desktop.

Finesse supports the following number of phone books:

• 10 global phone books

• 300 team phone books

The system supports a total of 50,000 contacts. The total number of contacts per agent across all phone books is limited to 1500.

Use the Manage Phone Books gadget to view, add, edit, or delete phone books and phone book contacts. Click the Name or Assign To headers to sort the phone books in ascending or descending order. Click the last Name, First Name, Number, or Note headers to sort the contacts in ascending or descending order.

The following table describes the fields on the Manage Phone Books gadget.

Actions on the Manage Phone Books gadget:

• New: Add a new phone book or contact

• Edit: Edit an existing phone book or contact

• Delete: Delete a phone book or contact

• Refresh: Reload the list of phone books or contacts from the server

• Import: Import a list of contacts to the phone book

• Export: Export a list of contacts from the phone book

Not Ready reason codes represent reasons that agents can select when they change their state to Not Ready.

Use the Manage Reason Codes (Not Ready) gadget to view, add, edit, or delete Not Ready reason codes. Click the Reason Label or Reason Code headers to sort the Not Ready reason codes by label or reason code in ascending or descending order. Click the Type header to sort and display system or custom reason codes. Click the Global header to sort reason codes by whether they are global (Yes) or not (No).

Not Ready reason codes can be global (visible to all agents) or team (visible only to agents on specified teams).

Note	Finesse supports a total of 200 Not Ready reason codes. This includes a maximum of 100 global Not Ready reason codes, and 100 Not Ready team reason codes. The team reason codes can be mapped to any team, and the same reason code can be mapped to multiple teams.

The following table describes the fields on the Manage Reason Codes (Not Ready) gadget.

Actions on the Manage Reason Codes (Not Ready) gadget:

• New: Add a new Not Ready reason code

• Edit: Edit an existing Not Ready reason code

• Delete: Delete a Not Ready reason code

• Refresh: Reload the list of Not Ready reason codes from the server

Note	When you add, edit, or delete a Not Ready reason code, the changes you make take effect on the Finesse desktop after three seconds. However, agents who are signed in when the changes are made must sign out and sign back in to see those changes reflected on their desktops.

When an agent signs in to the Finesse desktop, the agent state is set to Not Ready. The agent can then choose to go to Ready status or choose from one of the configured Not Ready reason codes from the agent state drop-down list.

If an agent wants to change from Ready to Not Ready status, that agent can choose the appropriate Not Ready reason code from the list of configured codes.

An agent who is on a call can select a state to be applied when the call is complete. For example, if an agent wants to be in Not Ready state when the call ends, that agent can choose Not Ready from the drop-down list while still on the call. The Finesse desktop shows the agent in Talking state and a pending state of Not Ready.

Pending state changes appear on the desktop while the agent's state is Talking (for example, on hold, in a consult call, conference, or silent monitor call).

Note	During a PG or CTI server failover, the pending state of an agent will not be retained.

Sign Out reason codes represent reasons that agents can select when they sign out of the Finesse desktop.

Use the Manage Reason Codes (Sign Out) gadget to view, add, edit, or delete Sign Out reason codes. Click the Reason Label or Reason Code headers to sort the Sign Out reason codes by label or by reason code, in ascending or descending order. Click the Type header to sort and display system or custom reason codes. Click the Global header to sort the reason codes by whether they are global (Yes) or not (No).

Sign Out reason codes can be global (visible to all agents) or team (visible only to agents on specified teams).

Note	Finesse supports a total of 200 Sign Out reason codes. This includes a maximum of 100 global Sign Out reason codes, and 100 Sign Out team reason codes. The team reason codes can be mapped to any team, and the same reason code can be mapped to multiple teams.

The following table describes the fields on the Manage Reason Codes (Sign Out) gadget.

Actions on the Manage Reason Codes (Sign Out) gadget:

• New: Add a new Sign Out reason code

• Edit: Edit an existing Sign Out reason code

• Delete: Delete a Sign Out reason code

• Refresh: Reload the list of Sign Out reason codes from the server

Note	When you add, edit, or delete a Sign Out reason code, the changes you make take effect on the Finesse desktop after three seconds. However, agents who are signed in when the changes are made must sign out and sign back in to see those changes reflected on their desktops.

When an agent clicks Sign Out on the desktop, any configured Sign Out codes appear in a drop-down list. The agent can then choose the code that represents why that agent is signing out.

For Not Ready system reason codes and Sign Out system reason codes, only the reason code label can be edited and saved. The Global attribute and system code cannot be modified. In case the system reason code label is modified and you wish to revert to the default label, refer to the following list of predefined system reason codes:

System Reason Codes are auto generated reason codes that may conflict with custom reason codes when upgrading from an older version to Cisco Finesse 11.6(1) or higher versions. If there is a reason code conflict then the following message appears when you sign in to the administration console:

Custom reason codes conflict with system reason codes. Resolve to avoid reporting inconsistency.

Note	Clear your browser cache to ensure that you are allowed to view and resolve system reason code conflicts.

All conflicting reason codes are highlighted. To edit, select each conflicting reason code and click Edit. The Edit Reason Code area appears. Select the reason code from the available options listed or enter any other code you wish. The code must be unique to the particular category (Not Ready or Sign Out).

Once resolved, the reason code gets sorted based on the reason code number and placed in the table accordingly.

Wrap-Up reasons represent the reasons that agents can apply to calls. A Wrap-Up reason indicates why a customer called the contact center. For example, you may have one Wrap-Up reason for sales calls and another for support calls.

You can configure Wrap-Up reasons to be available globally to all agents or only to specific teams.

Use the Manage Wrap-Up Reasons gadget to view, add, edit, or delete Wrap-Up reasons. Click the Reason Label header to sort the Wrap-Up reasons in ascending or descending order.

Note	Finesse supports a maximum of 100 global and 1500 team Wrap-Up reasons. No more than 100 Wrap-Up reasons can be assigned to any one team.

Note	If an agent is configured for wrap-up and selects a pending state during a call, when the call finishes that agent goes into the pending state selected during the call.

The following table describes the fields on the Manage Wrap-Up Reasons gadget.

Actions on the Manage Wrap-Up Reasons gadget:

• New: Add a new Wrap-Up reason

• Edit: Edit an existing Wrap-Up reason

• Delete: Delete a Wrap-Up reason

• Refresh: Reload the list of Wrap-Up reasons from the server

Note	When you add, edit, or delete a Wrap-Up reason, the changes you make take effect on the agent or supervisor desktop after three seconds. However, agents who are signed in when the changes are made must sign out and sign back in to see those changes reflected on their desktops.

Use the Manage Team Resources gadget on the Team Resources tab to assign and unassign phone books, reasons, custom desktop layouts, and workflows to teams. Click the Name or ID header to sort the teams in ascending or descending order.

The Manage Team Resources gadget contains six tabs, each enabling you to assign or unassign resources to a team. The tabs are defined in the following table.

Actions on the Manage Team Resources Gadget

• Add: Assign a phone book, reason, or workflow to the team

• Save: Save the phone book, reason, desktop layout assignment, or workflow to the team

• Revert: Cancel any changes made before they are saved

• Refresh: Refresh the list of teams

  Note	If you select a team and then click Refresh, the team is deselected and the Resources area for that team disappears. The list of teams is refreshed and you must select a team again.

Add or Delete a Team When Database Is Not Accessible

If you add or delete a team when Finesse cannot access the Finesse database, those changes do not appear in the Finesse administration console unless you restart Cisco Finesse Tomcat or the Cisco Unified CCX Engine.

You can use workflows to automate common repetitive agent tasks. A workflow has a unique name and a helpful description. Use the Manage Workflows and Manage Workflow Actions gadgets to view, add, edit, or delete workflows and workflow actions.

All workflows are team-level workflows. You cannot create a global workflow. If you need a global workflow, create a team workflow and assign it to all teams.

Finesse supports the following number of workflows and workflow actions:

• 100 workflows per Finesse system

• 100 actions per Finesse system

• 20 workflows per team

• 5 conditions per workflow

• 5 actions per workflow

• 5 variables per action

Click the column headers to sort workflows and workflow actions in ascending or descending order.

The following table describes the fields on the Manage Workflows gadget.

The following table describes the fields on the Manage Workflow Actions gadget.

Actions on the Manage Workflows and Manage Workflow Actions gadgets:

• New: Add a new workflow or workflow action

• Edit: Edit an workflow or workflow action

• Delete: Delete a workflow or workflow action

• Refresh: Reload the list of workflows or workflow actions from the server

You can configure workflow actions to be handled by the Finesse desktop or in a third-party gadget. A third-party gadget can be designed to handle the action differently than Finesse does.

Each workflow must contain only one trigger. Triggers are based on Finesse dialog events. Dialog events include the following:

• When a call arrives

• When a call is answered

  Note	If you set a workflow to trigger when a call is answered, the workflow runs when an agent answers an incoming call or makes an outgoing call, or when a customer answers an Outbound Option call.

• When a call ends

• When making a call

• While previewing a Direct Preview Outbound call.

The workflow engine uses the following simple logic to determine whether to execute a workflow:

• To determine whether a workflow should execute, its trigger set and conditions are evaluated against each dialog event received.

• The workflow engine processes workflow events for the first call that matches any configured workflow's trigger set and conditions. No other workflows run until this call has ended. If the agent accepts a second call while still on the first call, workflows do not run on the second call even after the first call has ended.

  Note	Outbound Preview calls are an exception to this rule. You can have a workflow run while the agent previews the call as well as when the agent accepts the call.

• After a workflow for a particular trigger type (for example, Call Arrives) executes, it never triggers again for the same dialog ID.

The workflow engine caches workflows for an agent when the agent signs in. Workflows do not change for the agent until the agent signs out and signs in again or refreshes the browser.

Note

Workflows that trigger when a call arrives, when a call is answered, or when making a call run whenever the browser is refreshed. When an agent refreshes the browser, the workflow engine sees the call as newly arrived or newly made. If an HTTP request action is part of the workflow, the HTTP request is sent when the agent refreshes the browser. Applications that receive the HTTP requests must account for this scenario. Otherwise, undesired results may occur.

An example of a workflow is a Call Arrival event that triggers an action that collects information from the dialog event (for example, the ANI or customer information) and displays a web page containing customer information.

You can filter trigger events by the value of the data that comes in the event. You can configure a workflow to execute if any conditions are met or if all conditions are met.

Individual conditions consist of the following:

• A piece of event data to be examined, for example, DNIS or call variables

• A comparison between the event data and entered values (for example, contains, is equal to, is not equal to, begins with, ends with, is empty, is not empty, and is in list)

When the trigger and its conditions are satisfied, a list of actions assigned to the workflow are executed. The actions execute in the order in which they are listed.

Workflows run only for agents and supervisors who are Finesse users. The Workflow Engine is a JavaScript library that runs client-side on a per-user basis within the Finesse desktop application. The desktop retrieves the workflows to execute for a user from the server when the user signs in or refreshes the browser.

Note	Changes made to a workflow or its actions while a user is signed in are not automatically pushed to that user.

It is possible to set workflows, conditions, and actions that are contradictory so that a workflow or action cannot function. Workflows are not validated.

If multiple workflows are configured for a team, the Workflow Engine evaluates them in the configured order. The Workflow Engine ignores workflows with no actions. When the Workflow Engine finds a workflow with a matching trigger for the event and the workflow conditions evaluate to true, then that workflow is the one used and subsequent workflows in the list are not evaluated. Workflows with no conditions evaluate to true if the event matches the workflow trigger. All workflows are enabled by default. Only one workflow for a specific user can run at a time.

The Workflow Engine retrieves dialog-based variables used in workflow conditions from the dialog that triggered the workflow. If a variable is not found in the dialog, then its value is assumed to be empty.

The Workflow Engine executes the actions associated with the matched workflow in the order in which they are listed. The Workflow Engine executes actions in a workflow even if the previously executed action fails. Failed actions are logged.

The Finesse server controls which calls are displayed to the Finesse user. If the user has multiple calls, the workflow applies only to the first call that matches a trigger. If the first call displayed does not match any triggers but the second call does match a trigger, the Workflow Engine evaluates and processes the triggers for the second call.

A call is considered to be the first displayed call if it is the only call on the Finesse desktop when it appears. If two calls on a phone are merged (as they are in a conference call), then the first displayed call flag value of the surviving call is used.

If the user has a call when the user refreshes the browser, the Workflow Engine evaluates the call as it is. If the dialog data (call variable values) change, the data may not match the trigger and conditions of the original workflow. The data may match a different workflow or no workflows at all.

If the user has multiple calls when the user refreshes the browser, the Workflow Engine treats the first dialog received from the Finesse server as the first displayed call. This call is not necessarily the same call that was the first displayed call before the browser refresh. Dialogs received for any other call are ignored because they are not considered first displayed calls. If dialogs for more than one call are received before the Workflow Engine is loaded after the browser refresh, no dialogs are evaluated because none are considered first displayed calls.

Workflows run for both Finesse agents and supervisors. The team to which the supervisor belongs (as distinguished from the team that the supervisor manages) determines which workflows run for the supervisor. You may want to put the supervisors in their own team to keep agent workflows from being run for them.

Finesse supports HTTP Strict Transport Security (HSTS) for increased security. HSTS is automatically enabled, in which case the Finesse server sends HTTPS responses indicating to browsers that Finesse can only be accessed using HTTPS. If users then try to access Finesse using HTTP instead of HTTPS, the browser changes the connection to HTTPS before generating any network traffic. This functionality prevents browsers from sending requests to Finesse using unencrypted HTTP before the server can redirect them.

With Finesse IP Phone Agent (IPPA), agents and supervisors can access Finesse features on their Cisco IP Phones as an alternative to accessing Finesse through the browser. Finesse IPPA supports fewer features than the Finesse desktop in the browser, but it does allow agents and supervisors to receive and manage Finesse calls if they lose or do not have access to a computer.

Supervisor Tasks

Finesse IPPA does not support supervisor tasks such as monitor, barge, and intercept, but supervisors can sign in and perform all agent tasks on their IP Phones.

Administration Tasks

After you configure Finesse IPPA, the administration tasks that you perform for the Finesse desktop also apply for the supported Finesse IPPA features. For example, the Call Variables Layouts that you configure for the desktop also apply for Finesse IPPA, although the column layout is modified to fit the IP Phone screen.

Reason Code Limitations

• On the IP Phone, Finesse can display a maximum of 100 Not Ready, Wrap Up, or Sign Out reason codes. If more than 100 codes are configured, the phone lists the first 100 applicable codes (global codes or applicable team codes).

• When Finesse IPPA displays reason codes, some IP Phone models truncate the codes due to character length limitations on the phone. To ensure they meet your requirements, verify the display of the reason codes on all phone models in your environment.

HTTP Only

Finesse IPPA phone clients communicate with the Finesse server using HTTP only, whether or not HTTPS access is enabled on Finesse.

Failure Behavior

Unlike the Finesse desktop, the Finesse IP Phone Agent does not automatically failover to the alternate Finesse server. To resume normal operations in a failure scenario, the Finesse IPPA agents must exit from the current Finesse IP Phone service and manually sign in to another configured Finesse service that connects to an alternate Finesse server.

To ensure continued operations in a failure situation, you must configure at least two Finesse IP Phone services in Unified CM, each pointing to different Finesse servers.

With One Button Sign In, you can set up the Finesse IPPA phones with prepopulated agent ID, extension, and password. In this case, agents can sign in to Finesse on the IP Phone without credentials just by selecting Cisco Finesse from the Services menu.

Alternatively, you can set up One Button Sign In and prepopulate only a subset of agent credentials. For example:

• You can prepopulate only the agent ID and extension, forcing the agents to manually enter their password at sign-in for increased security.

• You can prepopulate only the extension, forcing agents to manually enter their ID and password at sign-in (useful for agents who share the same phone).

You can use Unified CM Administration to prepopulate the agent credentials, or you can set up the agents with access to the Unified CM Self Care Portal to prepopulate their own credentials.

The following table shows examples of how you can assign the responsibility of defining agent credentials to the administrator or the agent, or share that responsibility between them.

To set up access to Finesse on agent IP phones in Cisco Unified Communications Manager, you must create the Finesse IP Phone service to which the phones can subscribe. To set up the Finesse service, you can choose one of the following options:

• Set up an enterprise subscription to automatically subscribe all IP phones in the cluster to the Finesse service. (Not supported with One Button Sign In.)

• Set up a manual subscription, and manually subscribe each IP phone to the Finesse service.

• Set up a manual subscription, and set up the agents with access to the Unified CM Self Care Portal to subscribe to the Finesse service themselves.

The following table lists the Finesse IPPA configuration procedures and indicates which procedures are required depending on the subscription option you choose.