Profile Search

UProfileResRsp.xsd

Profile Search is used to find profiles that exist in the database from a Profile Create request.

Profile Search allows the user to search for specific profile types using different variables for searching. The type of profile to search for is a required field. The possible profile types are:

For more information specific to a traveler profile search, refer to Profile Traveler Search.

This type of search is different than Child Search, which is used to identify all immediate children of a given profile.

The search looks for profiles that match all search parameters specified (i.e., an AND search, not an OR search). There are two types of search parameters: those defined by Travelport and those defined by the agency.

Schema

Profile Search is within uProfile.xsd. See the following transactions for Profile Search:

How To

Special rules apply to system-wide traveler profile searches; see Traveler Search for more information.

  1. The search request must contain the ProfileType attribute. You cannot search across all profile types.

  2. Specify the information on which you want to search.

    • Many parameters can be sent in a single search request. However, only profiles with all specified values are returned.
    • Searches are not case sensitive and ignore spaces in the search parameter. For example, searching for "abc 12" can return abc12, abc123, abc12fgh, AB C1.
    • Users must have the appropriate permission to search data that is masked or encrypted.

    Most profile data can be searched with wildcards. However, a wildcard (*) can only be specified at the end of a string. If no wildcard character is specified, only data matching the entire search value will be considered a match.

    • For example, searching for “abc12*” could return abc12, abc123, abc12fgh, ABc1 2&$f.

      • Exceptions: Encrypted and masked data cannot be searched with a wildcard. Encrypted data must be an exact match.

    • If any profile data has the same character as is used for the wildcard, it is considered a character in the data. For example, if the profile has “1234*” as a literal value in the profile, then searching for “1234” (with no wildcard value) does not return that profile. Searching for “1234*” would return that profile. Searching for 12345 would not return that profile.

    • Phone numbers cannot be searched using a wildcard.

    The following restrictions apply to searching for masked and encrypted data:

    • A wildcard is not permitted for data values that are masked or encrypted.

    • The following searchable fixed fields cannot be searched using wild cards: credit card number, credit card expiration date, debit card number, debit card expiration date, street, travel document number.

    • Searchable fixed fields and custom fields that are masked or encrypted can be searched.  

    Profile Type Search Parameters
    All
    • Name
    • Contract number
    • Travel document number
    • Contact data:

      • Given name, middle name, or surname

        Note: LocalLanguageGivenName and LocalLanguageSurname are not searchable.

      • Address
      • Phone
      • Email
    • Loyalty program data (supplier code and loyalty number)
    • Payment data (type, supplier, account number, expiry)

    • External identifier

      The ExtID attribute is required to search and wildcards are not allowed.

    Agency, Branch Group, Branch, Agent Provisioning Code
    Branch Provisioned address or phone
    Agent

    Given name or surname

    AlternateAgentID

    Traveler Given name or surname
    Account, Traveler Group, Traveler

    MidOfficeID

    The MidOfficeID can be used as a search criteria within ProfileTypeSearch for the elements AccountCriteria, TravelerCriteria, or TravelerGroupCriteria. Wildcard searches are available and are indicated by an asterisk (*). A minimum of two characters are required before the wildcard.

  3. Include optional search modifiers to limit search results.

    • Users can specify whether to return "agency type" children (i.e., agency, branch group, branch, agent) or "account type" children (i.e., account, traveler group, travel).

    • Users can specify whether to include/exclude agents and travelers.

    • Users can request a summary of the ancestors of each search result.

  4. Profiles that match all search values are returned. The profile search response sorts results by name. In the case of people (i.e., traveler or agent), results are sorted on surname first followed by given name. In the case of non-people, the organization name is used.

    Note: Only users with the appropriate permission are able to view unmasked data.

    For all profiles, the response includes the following:

    • The unique ID of the profile.
    • The current version of the profile.
    • The current status of the profile.

      • Note: Profiles with a status of Deleted are never returned in search results.

    • The unique ID of the Hierarchy Level that the profile is associated to, if applicable.

      • Note: Travelers are not directly associated to a hierarchy level.

    • If the profile has only one immediate parent, the Name of each ancestor of the profile to the root is returned. If the profile has multiple parents, the number of immediate parents is returned.  
    • When the search is for Agent profiles, the response includes:
    • The ID and Name both for the parent branch (i.e., the control branch) and the branch’s parent.
    • Agents associated to both the Control Branch and default Work Area Branch (WAB). Before Release 2.1, Profile Searches returned Agents associated only to the requested Control Branch.
    • Agents who have: An Emulated Branch as their default WAB. A Bridge Branch as their default WAB.
    • The ProfileSummary/ImmediateParentProfile/ControlBranch attribute, which indicates if the immediate parent of an Agent is a Control Branch or default Work Area Branch.

      • Note: This update is NOT backwards compatible for the ControlBranch indicator. This attribute is only available in uProfile v9.0 and later.

      ControlBranch helps administrators who manage multiple branches to get both default WABs and Control Branches returned as immediate parents for the requested Agents. These administrators can have access at any level, including System, Agency, Bridge Branch, and Branch.

      If ProfileSearchReq\ReturnParentSummary="True", then ProfileSearchRsp\ProfileSummary\ImmediateParentProfile @ControlBranch indicates that the parent is a Control Branch. If this new attribute value is none, the immediate parent branch will be considered as the Default Work Area Branch of the Agent profile.

      Note: Agency, Branch Group, Branch, Account, Traveler Group, and Traveler Profiles do not return this information.

    • Description of the profile.

    • Policy Reference for the profile, including :

      • Type: HRG Policy Group, Traversa Policy Group, Employee Grade
      • Value
      • Description
      • Controlling Policy ID.

        • If the Controlling Policy ID is not within the same agency hierarchy of the traveler, a warning is returned:ControllingPolicyID [XX] is not a valid id for the Policy Reference, where XX is the Profile ID.

      • Priority Order
      • Key
    • For Traveler and Agent, the following are the “minimal search results” that are always returned in the response message, regardless of whether the value was searched on:
      • First/Given Name

      • Last Name

        Note: If a Traveler profile contains a local language name, it is returned in the LocalLanguageName and LocalLanguageSurname attributes.

    • For all profile types besides Traveler and Agent, the following are the “minimal search results” that are always returned in the results, regardless of whether the value was searched on:

      • Name - For example, if the user searched for accounts only by a contract number, the Name (and the matching contract number) would always be returned in the results for each matching account.

        Note: If an Account or Traveler Group profile contains local language information, it is returned in the LocalLanguageName attribute.

    • The response includes any profile data matching the search parameters.
      • For example, if the user searched for travelers only by loyalty number 8744*, the results might have 4 travelers in the result set. Each would show only their loyalty cards that match 8744*.
      • That also means that if a given traveler had two loyalty cards that started with 8744, both card numbers would be returned in the search results for that traveler (but that particular traveler profile would be returned only once).
      • For example, if the user searched for travelers by both a loyalty number and a contact email address, the matching loyalty cards and matching email addresses will be returned for each traveler returned. (But other loyalty numbers and email addresses in the profiles returned, if they don’t match the search parameters, will not be returned.) 

How Templates Affect Searching

The templates identify the Travelport-defined Searchable fields.