Context Service Data Model, Fields, and Fieldsets

Document created by Cisco Documentation Team on Sep 13, 2016Last modified by Cisco Documentation Team on Jun 20, 2017
Version 8Show Document
  • View in full screen mode

Context Service is a flexible, extensible, secure data store in the cloud that stores your customer journey across any channel. Data includes voice, email, chat, mobile, and web. It enables Cisco Contact Center customers to deliver a seamless omnichannel, out-of-the-box, plug and play experience from Cisco Customer Care products and APIs for third-party integration.

Context Service stores customer interaction data in the cloud, enabling dynamic changes that allow businesses to be flexible in how they store and use data. Often information exists across multiple applications without an effectual way to bring it together. Context Service enables you to get a handle on disparate data and bridge the siloes, while creating a breadcrumb or a map of the data model. Breadcrumbs help your agents to follow a customer journey and provide relevant and immediate assistance, enhancing both the customer and the agent experience.

Context Service Objects

Context Service uses three main objects to store context data:

  • Customer data: Describes who the specific customer is, including information such as, name, address, and phone number. A Customer provides a way of linking personally identifiable information (PII) with a customer ID. It can also link to an existing data store that contains your customer data, with key fields, including name and account number, stored in Context Service. The agent desktop displays these details.

  • Activity: Also knows as POD, describes a specific customer interaction associated with a customer or request. It reflects one or more steps in a customer journey as the customer seeks the fulfillment of their specific request. The activity IDs tie together all objects within a particular customer journey. For example:

    • IVR menu that the customer selects.

    • Notes made by the agent.

    • A website URL that the customer has previously visited.

    • The chat metadata.

  • Request data: describes what the customer wants. Requests are about one or more customer interactions for a specific issue, at a high level. A Request reflects the customer's view of an issue, indexes customer journey and interaction, and is used to group related activities . For example, if a customer goes online to make a credit card payment, runs into an issue, and calls instead to make the payment. The separate activities represent these two transactions, but belong to same Request, making a credit card payment.

Context Service Fields and Fieldsets

Context data is stored in these objects as fields and fieldsets. A fieldset is a grouping of fields which is grouped with an inherent logic 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

Context Service objects can have multiple fieldsets assigned to them. You can use a specific field in multiple fieldsets and can assign multiple fieldsets to an object. The object remains within the bounds fieldset's scope.

You can use fields and fieldsets available by default or add your own custom fields and fieldsets. You can combine custom fieldsets that you create with the default fieldsets available with each object, to create a flexible, and dynamic data model.

For example, an activity for incoming calls and an activity for Mobile App shopping can have different fields. To store more data, you can add more fieldsets at any time. Fields in the newly added custom fieldsets are not marked as required. That is, the user is not required to enter data into the newly added fields. The example activities for incoming calls and Mobile App shopping app can have these fields:

Field Type

Activity for Incoming Calls

Activity for Mobile App Shopping

Fixed fields

Any field listed in the Fixed Fields table.

Any field listed in the Fixed Fields table.

Fields based on Cisco templates

  • Notes

  • Link ID


Custom fields

  • IVR Menu Selected

  • Caller Authenticated

  • Browsing

  • Cart

Each object comes with both a fixed fieldset and some suggested default fields. Each individual Context Service data object is limited to 256 KB in size.

Fixed fieldsets that are provided by Context Service, and managed by users include:


Activity object

Request object

Customer object

POD ID: Unique handle of this activity object.



Request ID: Unique handle of this Request object.

✓ - Links activities to Request object.


Customer ID: Unique handle of this Customer object.

✓ - Links activities to Customer object.


Date Time: Date and time the activity is created and updated

State: Indicates if the activity is active or closed.



Workgroup: Indicates if Context Service in working in lab mode or production mode. For more information, see Context Service Modes at

Contributors: Machine accounts that are integrated with Context Service. You can also add more identifiers to this field.



Media Type: Indicates the type of media of the activity. There are eight possible media types:

  • Voice

  • Video

  • Chat

  • Email

  • Mobile

  • Social

  • Web

  • Event



Fieldsets: One or more fieldsets attached to this activity.

Tags: List of tags for this activity.



Service managed fields are automatically populated when you create the object. Customers, or the application they use, can populate user managed fields.

You also get a Cisco template with predefined fields in a fieldset that you can modify. You can also create custom fields based on templates provided by Context Service.

For a complete list of base and custom fieldsets, see the Context Service SDK Guide.

Which Data should Be Stored in the 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, a PII can only be decrypted at the client.

  • Non-PII Encrypted—Information not associated with an individual, but 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 not confidential. It 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 specifying PII or confidential information into unencrypted fields. Make sure that your data is stored in the appropriate field with the correct classification.

You can also define security boundaries for your data based on the mode of Context Service. For more information, see Context Service Modes.