Context Service Data Model, Fields, and Fieldsets

Context Service is a flexible and secure data store in the cloud that connects the customer journey across different media channels. These media channels include voice, email, chat, mobile, and web. Information from different media channels often exists across multiple applications without an effective way to bring it together. Context Service enables you to better understand disparate data by creating a map of customer interactions. Context Service helps your agents follow the customer journey and provide relevant and immediate assistance, enhancing both the customer and the agent experience. Context Service enables Cisco Contact Center customers to deliver a seamless omnichannel experience through an out-of-the-box integration with Cisco Customer Care products and with APIs for third-party integrations.


Context Service Objects

Context Service uses four object types to store context data:

  • Customer data—Describes who a specific customer is. For example, this includes information such as name, address, and phone number. The customer object type provides a way of linking personally identifiable information (PII) with a customer ID.

  • Activity data—Describes a specific customer interaction. Activities are also known as PODs. Each activity reflects one step in the customer journey as the customer seeks to fulfill a request. For example, an activity occurs when a customer interacts with your organization by:

    • Browsing your organization's website.

    • Emailing your organization.

    • Calling your organization and using an IVR menu.

    • Chatting with an agent.

    You can associate activities with a customer or a request.

  • Request data—Describes what the customer wants. Requests are also used to group activities together that are related to a specific customer issue. For example:

    A customer goes online to make a credit card payment. The customer runs into an issue making the payment online, and makes a phone call instead. Attempting to make the payment online and making a phone call are two seperate activities. These two activities belong to the same request, making a credit card payment.

    You must associate each request with a customer.

  • Detail data—Provides additional information on another object type. For example:

    • Notes made by an agent during an activity.

    • Feedback from the customer about an activity.

    You must associate each detail with a request or an activity.


Context Service Fields and Fieldsets

Fields allow you to define the structure of the context data that is stored in Context Service objects. Fieldsets are logical grouping of fields based on your business needs. For example, you can create a shopping basket fieldset with four fields:

  • Items in the cart.

  • Items in a wish list.

  • Total price.

  • Estimated shipping costs.

You can the Context Service fields and fieldsets to create a flexible data model. You can:

  • Use the Cisco base fields and fieldsets or create your own custom fields and fieldsets.

  • Add a field to multiple fieldsets.

  • Associate multiple fieldsets with a single Context Service object.

  • Associate the Cisco base fieldsets and your own custom fieldsets with the same Context Service object.

  • Add or remove fields from a fieldset without changing any of the objects that are associated with that fieldset.

  

Each Context Service object must have at least one fieldset assigned to it.

For example, you could use different fields for an activity for incoming calls and an activity for Mobile App shopping:

Field Type

Activity for Incoming Calls

Activity for Mobile App Shopping

Cisco base fields

  • Context_Notes

  • Context_POD_Activity_Link

 

Custom fields

  • IVR Menu Selected

  • Caller Authenticated

  • Browsing Information

  • Cart Items

Each individual Context Service data object is limited to 256 KB.

Context Service Object Properties

Object Property

Activity

Request

Customer

Detail

id: Unique object identifier.

parentId: Unique identifier representing a parent Context Object.

✓ Optional property that links the activity with a request.

N/A

N/A

✓ Required property that links the detail with either a request or an activity.

customerId: Unique identifier representing a customer.

✓ Optional property that links the activity with a customer.

✓ Required property that links the request with a customer.

N/A

N/A

created: Object creation time stamp.

lastUpdated: Time stamp of when the object was last modified.

state: Indicates if the object is active or closed. For more information, see Object State in the Context Service SDK Guide.

contributors: Users or Machine accounts that created or updated an object.

mediaType: Indicates the type of media in activity. There are eight possible media types:

  • Voice

  • Video

  • Chat

  • Email

  • Mobile

  • Social

  • Web

  • Event

N/A

N/A

N/A

fieldsets: The fieldsets assigned to the object. Object must have at least one fieldset assigned. Fieldsets define which fields apply to the object.

tags: List of tags for the activity.

N/A

N/A

N/A

The object properties id, created, lastUpdated, contributors, and state are automatically populated when you create an object.

For a complete list of Cisco base fields and information on creating custom fields, see Fields and Fieldsets in the Context Service SDK Guide.


Which Data Should Be Stored in Context Service Objects?

Context Service provides a way for you to collect siloed information and creates breadcrumbs that allow you to follow a customer journey. You can design the data stored in the Context Service objects based on your business requirements and workflows. Before you decide about what data to store, consider these questions:

  • Which kind of data do you need to help you solve your specific use case?

  • Where is the information you need currently stored?

  • Who needs access the information to solve your specific use case?

Examine the journey that your customer follows. This helps to not only answer these questions, but also to find the best way of bringing the disparate pieces of information together. For example, the customer starts on online on a website and follows up with a phone call. Does your IVR or agent know about the previous website visit? Can your IVR identify a repeat caller and offer different options? Use these observations to identify application silos or organizational silos in the user journey. Identify the gaps in the information and build a Context Service data model to provide the breadcrumbs required to fill the gaps. For example, an online retail organization who wants to see if customers added items to their cart and did not buy them. The organization also wants to offer alternate suggestions based on the product customers are looking for. The object, an activity here, must have two fields. One that records the items in the customer's cart and one that lists all the products browsed. The data model design is also dynamic, that is, you can choose to add new fieldsets any time. The online retail organization decides after few months, that survey score information adds value. They can then add a survey score field to the design, without impacting existing Context data.

Context Service Data Privacy Model

Each field is defined by a data type and a security classification.

Context Service provides endpoint encryption so that sensitive data is not stored or transported in plain text. When you define a field, you specify how the field classifies data. You can classify data as:

  • Personally Identifiable Information (PII)—Information associated with an individual who contacts your support center. PII is stored and transported in an encrypted format and requires a key to access the data. With endpoint encryption, PII can only be decrypted at the client.

  • Non-PII Encrypted—Information that is not associated with an individual, but is considered confidential. Encrypted data is stored and transported in an encrypted format. Encrypted at endpoint, this data can only be decrypted at the client.

  • Unencrypted—Information that is not PII and is not confidential. Unencrypted data is stored as plain text, but transported over an encrypted layer (HTTPS).

For example, name, email, and phone-number are personally identifiable. Therefore, the default fields that hold these types of data classified as PII, and are endpoint encrypted. Rewards card balances may not be PII. You can store them as Unencrypted. Non-PII Encrypted fields may be fields such as "Context Title", the title of an activity.

  

Context Service does not prevent you from entering PII or confidential information in unencrypted fields. Ensure that your data is stored in the appropriate field with the correct classification.

You can also define additional boundaries for your data by using lab mode and production mode. For more information, see Context Service Modes.

Was this article helpful?