Creating a Client’s Agency Hierarchy

This topic provides information about how agency hierarchies are created, as well as the benefits that they provide. This topic also contains hierarchy scenarios for some of the different ways in which a hierarchy may be created, based on an agency’s organizational structure.

When an client application is ready to use Universal API, the agency or travel provider must have an Agency hierarchy created for them by Travelport.

See the Profiles Glossary for definitions of the terms and concepts used for Universal Profiles.

High-Level Steps for Creating an Agency Hierarchy

The Travelport Sales team meets with a client to discuss and evaluate the client’s business organization. For example, is the client’s business small (e.g., one or two points of sale) or large (e.g., multiple points of sale across multiple geographies)?

Small clients only require one Branch Group level and one Work Area Branch per point of sale.

Large clients may require multiple hierarchy levels.

Sales and the client sketch the Agency hierarchy.
Sales and the client complete a spreadsheet that defines the hierarchy levels and the information that pertains to each level.

The spreadsheet and hierarchy sketch are then used by Travelport to build the Agency hierarchy. The client is notified when the Agency hierarchy is built. The agency administrator can then begin building the Account hierarchy (i.e., corporate accounts).

Account hierarchies are built separately from the Agency hierarchy. As the client is a customer of Travelport, Travelport is responsible for building the Agency hierarchy. Account hierarchies are created for corporate customers and other travelers, who are all customers of the agency. Therefore, it is the responsibility of the customer to build the Account hierarchy. Please refer to the Admin Portal documentation for more information on building account hierarchies.

Hierarchy Overview

A hierarchy is a collection of hierarchy levels. Each level defines a kind of profile the agency has. Hierarchy levels define the permitted relationships among profiles. Each hierarchy level contains a corresponding template. Templates, in turn, define the kind of data permitted within a profile at that level. Templates also act like a style sheet for a level; they allow administrators to define field labels, field cardinality, and whether a field is shown or hidden.

Benefits of a Hierarchy

A hierarchy is created so that clients can target specific parts of their business with different rules and preferences. Each piece of information is associated with different parts of hierarchy. Preferences, rules, and workflows set at the top level (i.e., Agency) will influence the client application's behavior.

For example, a large agency with multiple franchises has a contract with carrier YZ for a certain minimum yield per month. That agency may set the carrier YZ as a preference at the top hierarchy level. However, one of that agency’s franchises may have a contract with carrier AB for a certain city pairs. The franchise can preference carrier AB above carrier YZ for those city pairs.

A client’s hierarchy depends heavily on the way in which its business needs to divide rules and preferences (e.g., per country or per brand). Physical office location is the bottom-most Branch Group in most hierarchies.

Another benefit of hierarchies is that when new versions of a client application are deployed, the agency administrator can give access to the new version of the application to a certain group of users to test before it is deployed to the entire agency.

Understanding Hierarchies

There are five anchor points (i.e., required hierarchy levels) within a hierarchy. These anchor points are listed below from highest to lowest hierarchy level:

Agency
Work Area Branch
Agent
Account
Traveler

Additional hierarchy levels, called groups, can be inserted into the hierarchy:

One Agency Group can be added above the Agency level, making the Agency Group the top hierarchy level.
Up to seven Branch Groups can be added between the Agency and Work Area Branch levels.
Up to eight Account Groups (traveler groups) can be added between the Account and Traveler levels.

Of these hierarchy levels, the client investigation meetings are concerned with mapping the Agency, Branch Group, and Work Area Branch levels, as these levels are the ones that are created during initial setup. Account and Traveler Group hierarchy levels are set up by the client once the Agency hierarchy is in place; therefore, this document does not address these levels in detail.

Work Area Branch

A Work Area Branch is a point of sale, which contains PCC (Pseudo City Code), provider info, currency, country, ACH information, and RCS information. A Work Area Branch is also referred to as a “branch.”

Agents are assigned to either Branch Groups or Agencies directly, then they emulate into Work Area Branches. Because agents are not assigned to Work Area Branches, if there is not at least one layer of branch grouping in a hierarchy, all agents are assigned to the agency. By inserting a Branch Group, agents can be divided into groups (e.g., Shop1, Shop2). For more information, see Agents and Hierarchy.

Travelport strongly recommends that each agency hierarchy contain at least one Branch Group hierarchy level, which provides room for growth if the agency ever expands.

The bottom-most Work Area Branch defines a single shop (i.e., a physical office location) so that agents can be associated with that shop.

Hierarchy Limits

Each client, no matter their size, has the following hierarchy levels: Agency (only one), Branch Group (1 to 7), and Work Area Branch (one to many).

There is a maximum of 10 hierarchy levels from Agency to Agent, inclusive. As Agency, Agent, and Work Area Branch are required levels, there are seven remaining, configurable levels available to a client.

Performance of Universal API and its client applications degrades as the number of hierarchy levels increases. It is important to capture the client’s business organization (defined by the way in which the client needs to apply preferences and rules), but it is also important not to add irrelevant levels. With each additional level added, processing overhead increases.

Templates

Each hierarchy level is associated with a template. Templates define the structure in which to display/treat relatively “flat” profile data at each hierarchy level. Templates act like a style sheet for a level; they allow administrators to define field labels, field cardinality, and whether a field is shown or hidden.

Templates are modified by the client and are not part of provisioning. For more information about templates and how they affect profiles at each hierarchy level, see the Profiles topics.

Universal Profiles

Universal Profiles are non-GDS profiles specific to Universal API that contain data that feed the shop/book process. After hierarchy levels are in place, profiles can be associated with a hierarchy level, which identifies the type of profile it is. The data that can be included in a profile depends on the hierarchy level to which that profile is associated. For example, only profiles at the Agency level can have advisory data, and only profiles at the Traveler level can have loyalty cards.

Hierarchy Scenarios

By adding group levels within an Agency hierarchy, the agency can closely match the hierarchy to their business model. The lowest hierarchy level, Work Area Branch, represents the physical office location, and agents are then associated with their particular office.

In the following example, a large, multi-national agency named TravelPros divides its business by region, country, other geographical region (e.g., state, province), and finally by office location. This business model may be defined by the following hierarchy structure.

Figure 1: Hierarchy for a Large, Multi-National Client

The bottom-most hierarchy level relates to a physical shop location. Notice that agents are associated with either Agency or Branch Group levels. Agents cannot be directly associated with a Work Area Branch. Rather, agents emulate into a Work Area Branch in order to shop and book (see Agents and Hierarchy for more information). Work Area Branches contain all information necessary to run a transaction, including information about GDS, RCS, and ACH providers.

Another multi-national may have multiple internet-based businesses as well as store-front businesses. This client may decide to divide the business as follows:

Figure 2: Hierarchy for a Large Client with Internet Business and Storefront

A small agency with only two storefronts has a less complicated hierarchy. However, a Branch Group level is strongly recommended for every hierarchy to allow room for expansion. Because agents can only be assigned to Agencies or Branch Group levels, adding a Branch Group level allows a client to divide its agents into different groups. For more information about how agents are associated to agency and Branch Group levels, see Agents and Hierarchy.

Figure 3: Hierarchy for a Small Client

Agents and Hierarchy

As in the traditional GDS environment, Travel Consultants emulate into Pseudo Cities in order to transact. The emulation process defines information relating to the point of sale from which the Travel Consultant is working, and defines the content sources that can be shopped and booked. Additionally, the emulation process collects hierarchical profile data from the point of view of the Shop emulated by the Travel Consultant, thereby allowing clients to make preferences, rules, policy and workflow available globally (i.e., at the Agency hierarchy level) or at any level in the hierarchy.

Figure 4 shows a Travel Consultant emulating a physical office location (i.e., Work Area Branch hierarchy level) in the Universal Profile system, based on the hierarchy scenario provided in Figure 1.

Figure 4: Example of a Travel Consultant's Emulated Hierarchy

Emulated Hierarchy Profile Data

The emulation process collects hierarchical profile data that can be used to direct the booking workflow of Travel Consultants using a Universal API client application. Therefore, the Travel Consultant in Figure 4 is using a combination of preferences defined at the following hierarchy levels: agency (i.e., TravelPro), region (i.e., Americas), country (i.e., USA), state (i.e., New York), and Work Area Branch (i.e., Smith Travel, which is a physical shop location).

Figure 5 shows the agency data that can comprise a Travel Consultant’s emulated profile hierarchy. Hierarchical profile data is used by rules and policy and is evaluated by the client application to direct booking workflow behavior.

Figure 5: Profile Data Associated with Each Level

Account Hierarchy

Account hierarchies are used by the client to divide its travelers by groups. Accounts are used to define a corporate customer of an agency. Account hierarchies are used to structure account preferences. For example, a company may have different preferences for their Asian organizations versus their Americas organizations.

Account hierarchies are not created during provisioning. However, the following diagram is given to provide a complete, overall picture of a hierarchy.

Figure 6 illustrates how Agency hierarchy and Account hierarchies are related. The Agency hierarchy (left) contains data relating to the client’s business and is used by the client application when Travel Consultants (Agents) shop and book itineraries for leisure and corporate travelers according to the client’s business rules. The Account hierarchy (right) contains similar data relating to each of the client’s corporate customers (Accounts). Data in Account hierarchies can be used by client application as Travel Consultants book corporate customers, to ensure that itineraries are compatible with corporate preferences and policy.

Notes:

During initial setup, only the Agency hierarchy needs to be determined. The client creates their own Account hierarchy using the Admin Portal.
The labels used in the diagram below can be configured to be consistent with terminology understood by the client.

Figure 6: Universal Profile Hierarchies

How Hierarchies Are Created

The table below indicates which profiles are created by Travelport during initial setup and which profiles are created by the agency administrator.

Profile	Data Description	Travelport	Agency Admin
Agency Groups	The top level of the Agency hierarchy. Agency Groups can never be a Contracted Level. They are used only for storing workflow and rules for agency consortia.	No	Yes
Agencies	Agencies are always created at the time an Agency hierarchy is first provisioned in the Universal Profile transactional system. Agencies may or may not be Contract Levels, depending on the client’s relationship with Travelport. Agencies are the top hierarchy level if Agency Groups are not present.	Yes	No
Branch Groups	A configurable number of hierarchy levels can exist between Agency and Work Area Branches. These levels are called Branch Groups and can be created by Travelport when the hierarchy is first created, or created/modified post-setup by support users using Admin Portal tools.	Yes	Yes
Branches, also called Work Area Branches	The bottom level of the Agency hierarchy. Work Area Branches do not contain users; rather, they contain GDS and direct-connect supplier credentials. Users emulate into Work Area Branches to transact (shop/price/book/ticket) using the supplier credentials linked to the Work Area Branch.	Yes	Yes
Agency Admin Users	Agency Admin users have the ability to emulate into any Work Area Branch of the Agency hierarchy and view/edit agency data.	Yes	Yes
Support Users	There are two types of support users: Global Support Users are users with permission to emulate into Work Area Branches of any client and edit their entire agency configuration without limit. Regional Support Users are users authorized to emulate and edit Work Area Branches and parts of the client’s profile hierarchy supported by the Support Organization to which the Regional Support User is associated (works for).	No	Yes
Agents	Travel Consultants created by support Admin users or Agency Admin users after an Agency hierarchy has been created.	No	Yes
Roles	A set of permissions that can be assigned to agencies, Work Area Branches, and agents to define the Travelport products and services that an agent is authorized to use.	Yes	Yes
Access Credentials	Configuration data such as web service credentials and terminal IDs used by the system to access the services of provider systems such as the GDSs and direct-connect suppliers.	Yes	Yes
Bridge-Branch	Relationships Associations between agents and Work Area Branches in the system. Currently a Bridge-Branch Relationship allows an agent to retrieve Universal Record and Universal Profile data associated with branches other than the primary branch to which they are related.	No	Yes

Provisioning GDS and Direct-Connect Provider Access

By associating GDS access credentials and direct-connect access credentials with Work Areas, Universal API services can access an aggregated set of content providers associated with the work area into which a user emulates. GWS Host Access Profiles (HAPs) provide access to 1G and 1V hosts. Universal API interaction with the 1P host relies on custom HAPs that will store the relevant IP access details. Agency Administrators are required to administer their own access credentials for 1S and 1A hosts.

Role-based security determines whether an agent can emulate a work area, and the list of distinct relationships between the user profile and work area determines the specific Work Areas into which agents can emulate. Once emulated into a work area, the GDS and direct-connect provider credentials associated with the work area are used to access an aggregated set of content providers.

Each work area has at most one set of access credentials per GDS, which means that a work area may have no GDS access credentials (in the case of a configuration supporting direct-connect providers only). The list of all content providers associated with a work area defines the aggregated set of content providers from which users see results when shopping. If more than one GDS content provider is specified, shopping results include data from both GDSs and direct-connect providers.

Client Information

The following spreadsheet provides an example of the information that is required by Travelport to create any new global or national hierarchies. Your Travelport Sales representative will work with you to determine the data necessary for your implementation of Universal API.