Tags

Tags are a means of “marking” profile data to allow the profile to be filtered. The agency can apply zero, one, or many tags to each profile data (up to a system-level defined limit). Then, when a filter is applied, only data marked with a given tag or tags will be shown to the user or applied to some activity. For example, a traveler’s profile may have two credit cards, one tagged for Company Travel and the other for Personal Travel. Similarly, the profile may have different preferred hotels, airline seats, meal types, car sizes, travel documents, etc. tagged with one of those categories. The profile could have some data tagged with both categories, and some with neither. The agent would then be able to pick one of these categories and see only the FOP, meal type, travel documents, etc. associated to the selected filter (tag).

Tags are associated to profile data by the tag ID or code.

Tag Services

The following services are available for tags:

• Create Tags

• Search Tags

• Modify Tags

• Delete Tags

Assumptions

• Tags are associated to profile data by the tag ID or code, not by any unstable attribute such as the tag Name. Thus simply modifying an existing tag requires no updates to the profile data tables.
• Not all data is taggable. Templates are used to indicate to the client what level of data is taggable. The template fixed fields/groups indicates at which level the data is taggable.
Show taggable fields

Not every fixed field or field group is taggable. The following fixed fields are taggable:

• Contract

• Travel Document

• Loyalty Program Enrollment

• Alternate Contact

• Address (Alternate Contact & any profile type that has this data element)

• Phone (Alternate Contact & any profile type that has this data element)

• Email Address (Alternate Contact & any profile type that has this data element)

• Payment Details (Address can not be tagged within payment details)

• Air Preference

• Hotel Preference

• Car Preference

• Rail Preference

• Other Preference

• Remarks

For field groups, child fields can be tagged separately from the field group. If a tag is added to a child field, no tag is added at the root level. If a root level is tagged, then each child is also considered tagged. The following examples describe field group tagging scenarios:

• Each passport (i.e., each travel document) can be tagged. Its individual components (number, issuing country, gender, name on passport, etc.) cannot be tagged.

• Each loyalty card can be tagged. Its individual components (vendor, number, status, etc.) cannot be tagged.

• Each contact can be tagged. Individual contact mechanisms, such as each phone number, each electronic address, each physical address, can also be tagged.

• Each payment type (cash, credit, check) can be tagged.

• Each payment method can be tagged, but its attributes (issuer, exp date, number, name on card) cannot be tagged.

• For nested field groups, the root data level can have a different tag than each of the children data levels. For example, alternate contact has nested field groups within it. Alternate contact name and relationship can not be tagged; however, each phone, address, or email data grouping within the alternate contact can be tagged.

• Each air preference could be tagged, as could some of its components. For example, each SSR could be individually tagged differently than its parent set:

  • Air Pref Chicago, Aug 31 Meal type Veg [Tag= Leisure]

  • Air Pref Chicago, Aug 31 SSR Wheelchair [Tag=Corporate]

  • Air Pref Meal type Kosher [Tag= Leisure]

Common Functions and Rules

• Any type of profile can be tagged (not just traveler profiles).

• Custom fields/groups will only be taggable at a top field group and stand-alone field level. The agency cannot configure this rule.

• Of fixed fields, the system must indicate (e.g., via templates) what level of fields and groups are taggable.

• Contract

• Identification Travel Document

• Loyalty Program Enrollment

• Contact Mechanism (address, phone, email)

• Payment Method Details

• Travel Preferences (this is going to be by product type Air, Hotel, Car, Rail, other)

• Tags will only be supported at the Agency level.

• No canned tags are provided.

• Each agency can own no more than 15 tags.

• Data can be marked with 0-2 tags.

• Tags will not have a concept of hide/show, the only way to remove or hide tags is to delete them.

• Within an ownership context, the tag name must be unique.

• Name uniqueness must be case-insensitive. So for example a tag named Corporate and CORPORATE and corporate and corporate are all overlapping and would not be permitted to be separate tag names.

• The tag create service permits creating multiple tags in a single request.

• The tag modify service permits modifying multiple tags in a single request. The items may be dependent on each other. For example, a single request could permit renaming two tags, one to use the former name of the other, and validation of name uniqueness will not fail.

• The tag delete service directly or indirectly triggers a deletion of the tag from all profile data using that tag.