The list of interaction properties

Create and delete interaction properties from the properties list panel. The delete property button will open a dialog box requesting confirmation.

Deleting an interaction property

Configuring an interaction property

1.Property Name – This name will be the label displayed within the Topics page and on forms where the property is entered.

2.Property Type – There are four types of interaction properties: Case, Question, Answer, and Knowledge Base. The Knowledge Base property type is only used within the knowledge base articles. There will always be only one value saved in the database for case properties, but question and answer properties can have values associated with each individual question or answer.

3.Value Type - Values are stored in the database using one of 5 formats: Date, DateTime, Number, Integer (whole number), or Text. If the property will be a list selection, choose that list from the drop down menu. These lists are created at the Tenant level within the lists page.  If the property will contain free form text, just select Text. When Text is selected, and option to input multiple lines of text will appear.

4.Required - When a property is marked as required, it is outlined in red and a user must enter a value. In general, required interaction properties must be entered before the interaction can be resolved. See Required Properties for more details.

5.Shared Property – Interaction properties are specific to the segment in which they are created, and appear in the topic menu for association. Turning on the Shared Property switch causes the property to be displayed in the topics page for all segments. They can be used to capture values for interactions in the other segments when they are shared. For example, a property like Urgency might be relevant to several segments. Making the property shared allows all segments to use the property in their topic configurations.

Properties shared from another segment

It is important to note that once a property value is set on an interaction, it remains even if the interaction is forwarded to a different segment. This does not require the shared setting.

6.Allow Multiple Values – This attribute will place a [+] next to the property allowing agents to enter multiple values. For instance, a property of type phone number might allow several different numbers to be entered.

▪Has Descriptions – If the value allows multiple values, it might be desirable to provide a description for each value. For instance, an additional detail for types of phone numbers might be created with values of Home, Office, and Mobile. This additional detail would be selected in item 7 – Value Description Type. The list of Additional Details is enabled in item 7 when the Has Description box is checked.

▪Value Description Type – This is a list of additional details created in Admin Tools > Additional Details. The list will be used as the description for the Multiple Value property.

7.Customer Viewable – If the property is customer viewable, it is displayed to the contact in customer portals. It will not be listed in contact forms, and the contact can't change the values.

▪Customer Editable – If the property is customer editable, it will be displayed to the contact when they use contact forms and can be edited by the contact in customer portals. In order to automatically display a property to a customer on an Ask a Question form, both the Customer Viewable and Customer Editable fields must be selected, and the property must be associated with a topic.

Perhaps you want to categorize the types of conversations you have with customers using a property with a drop down list of values like Training Needed, Defect, Enhancement Request. This type of property would be related to the entire conversation, and not an individual question or agent answer within the case.  In this example the Case Property would be most appropriate because it describes the entire "case", or message thread.

Case properties are the most common type of property used. All properties created within a workflow are case properties with only one value.

If you want to document something about each question the user submits, like their level of satisfaction, you would use a question property. Question properties can have a different value for every question within the case (message thread).

After you create the interaction property you have the option to associate it with a set of topics as shown in the Topic section of this user guide. When a user selects that topic in the Ask a Question form of a customer portal, the properties associated will be automatically displayed if they are set as both customer viewable AND customer editable. However, the property will be shown to an agent in the Create Ticket page because agent's have access to those properties regardless of the customer view and edit settings. NOTE: While the association of the property with a topic determines when the question property will appear in the standard iService GUI, you can create custom forms that include any interaction property regardless of the topic configuration.

When the question is presented to an agent in the Msg Queue page, the value entered on the original question will be displayed in the Message Properties panel. The agent can change this value, which is associated with the incoming question and NOT their answer.

Perhaps you want the agent to designate their response as billable and document the minutes spend working on a solution. This would require an Answer Property, and every response from the agent could have a different value. Their first response could be marked as billable and 10 minutes of time. If the customer replied saying thanks, they could resolve that question and mark their resolution as Not Billable and 0 minutes of time. The answer values are separate for each answer created (agent response, private or public note, agent email, etc), and updating their values has no impact on other answer or question properties.

Interaction properties can be marked a "Required" to ensure that information is consistently captured. Marking a property as required has a different impact depending on the type of property: Question/Case or Answer.

Question and Case Property Rules

When a required property is set on a question or case, the following rules are enforced.

1. Customer emails are exempt from the required rule since it is can't be enforced consistently without filters.

2. Customer ticket form submissions return a standard error when the property is not included. For manually prepared forms, be sure to include all required fields for the topic for the user to populate. If you create a form that submits to a topic with required properties, the customer will not be able to submit the form if they are excluded from the page.

3. Properties that are not customer editable are not displayed to customers when a customer submits a Customer Ticket form. Therefore the property is not required to create the interaction.

4. Questions created without a required question property (e.g., customer emails or forms submitted where the property was not customer editable) can't be resolved by an agent until a value is set.

The Agent Ticket forms behave differently from Customer Ticket forms. Agents do not have to enter the property value until the interaction is resolved.

Answer Property Rules

When a required property is set on an answer, it must have a value entered before the answer interaction is resolved.

Displaying required interaction properties

Required interaction property labels are displayed in a bold, red color to alert the agent that a value must be entered.