WO2017125879A1 - Determining approval parameters of potential itineraries - Google Patents

Abstract

A method and system is provided for carrying out approval of business trips by evaluating selected parameters. Approval routes can be configured based on factors associated with a multi-tenant environment, such as security, company policy, geographic region of the customer, local rules and regulations of the jurisdiction, and more. A traveller's profile can be input into the system. Approval routes for the business trip are provided by the requesting traveller, the employer, or by another individual or entity. Approval routes, which configure communications paths, can be dynamically configured and modified. Tasks to be executed in connection with the approval determination can be provided. Approval rules are consulted in determining whether the trip is approved.

Description

DETERMINING APPROVAL PARAMETERS OF POTENTIAL ITINERARIES

[0001] Businesses have an interest in ensuring that business journeys undertaken by employees meet certain requirements. Such requirements can include purpose of trip, duty-of- care capabilities, assessment of a risk level and other safety information for a specific destination, and travel budget. It would be desirable to accomplish this prior to booking the journey, rather than waiting to prior to ticketing. Where prior to booking, the journey is a potential journey in the sense that no commitment has been made; where prior to ticketing only, it is assumed that a booking has already been made. Depending on the circumstances, making the booking can create impediments that can include partial or full non-refundability, and an inefficient use of resources in the reservations process.

DRAWINGS

[0002] FIG. 1 is an example computing environment for assisting with determining approval parameters of potential itineraries.

[0003] FIG. 2 is an example process for determining approval parameters of potential itineraries.

[0004] FIG. 3 is an example user interface that can be used in connection with determining approval parameters of potential itineraries.

[0005] FIG. 4 shows example application components that can be used in determining approval parameters of potential itineraries.

[0006] FIG. 5 illustrates an example architectural deployment that can be used in connection with determining approval parameters of potential itineraries. SUMMARY

[0007] In embodiments, disclosed is a computer-implemented method and system for determining approval routes within an organization for business travel which can comprise identifying an attribute of a travel request by the employee, a software resource used for facilitating the approval of the travel request, and a tenancy relationship between the software resource and the organization. Based on the above an approval route can be configured, based on the tenancy relationship between the software resource and the organization, and a predetermined rule for determining a parameter of the approval route. Further, in embodiments the tenancy relationship can be based in part on identifying two geographic regions served by the software resource. A predefined approval route for a first geographic region can be non-identical to a predefined approval route for a second geographic region. The tenancy relationship can be based in part on identifying two organizations served by the software resource. Further, a predefined approval route for a first organization can be non-identical to a predefined approval route for a second organization.

[0008] Budget considerations can influence the nature of the predetermined rule. Such budget considerations can relate to whether a predetermined percentage or amount of the budget in connection with a time period has been exceeded. The predetermined rule for determining a parameter of the approval route can be based on a risk assessment of the destination of the travel request, and/or seniority of an approver within the approval route (e.g., position within an organization). The predetermined rule for determining a parameter of the approval route can be based on a role associated with an approver. The approver can be associated with two roles. The predetermined rule for determining a parameter of the approval route can be associated with a trust level accorded the employee based on objective metrics derived from past requests by the employee. The predetermined rule for determining a parameter of the approval route can include an offline communication or action associated with the approval process.

[0009] Still further, in embodiments a computer-implemented method and system for determining an approval route within an organization for authorizing a travel request of an employee of the organization is disclosed, which can comprise identifying the attributes of a travel request from the employee, receiving a first approval route requested by the employee, identifying a second approval route based on predetermined rules set by the organization, comparing the first and second approval routes, and identifying the similarities or differences between the first and second approval routes. The above approval route can be based on identifying the similarities or differences between the first and second approval routes, wherein the organization establishes an authorized approval route for this travel request. Differential weighting is accorded elements of the employee's request and the organization's predetermined rules.

[0010] Still further, disclosed is a computer-implemented method and system for determining an approval route within an organization for authorizing a travel request of an employee of the organization, based on identifying an attribute of a travel request by the employee, identifying a first approver associated with the approval route, identifying a second approver associated with the approval route, wherein the second individual is at an organizational level higher than the first individual, and making an approval determination based in part on whether a travel budget for a specified period has been exceeded. DETAILED DESCRIPTION

[0011] Reference will now be made in detail to several non-limiting embodiments, including embodiments showing example implementations. The figures depict example embodiments of the disclosed systems, platforms and/or methods of use for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative example embodiments of the systems and methods illustrated herein may be employed without departing from the principles described herein.

[0012] In embodiments a traveller can complete an online travel request (OTR). The request can be screened against client-defined parameters, and forwarded to an approval function for review. Such approval function and individuals in support thereof can approve the OTR, reject the OTR, request more information, or conduct other activities. Once a request is approved, the system can issue a unique code used to "unlock" the travel booking process. An entity such as a travel management company (TMC) or other entity can prepare an itinerary and proceed with the booking process. In embodiments, a traveller may proceed with booking via an online booking tool (OBT). An administrator of the system can have the ability to access the system to provide support for travellers, the approval function and individuals in support thereof, and TMCs or other travel entities.

[0013] FIG. 1 can illustrate a computing environment 100 for assisting with determining approval parameters of potential itineraries. Approval determination server 130, which can carry out multiple actions, functionalities and processes, can be operatively associated with travel database 140, as by a network 120. Travel database 140, which can comprise multiple databases, can comprise extensive travel record information associated with many individuals and entities, storing or having access to individual profiles, entity profiles, travel reservation information, and any relevant information related to travel. Network 120 can represent a network or numerous networks of any logical or physical size such as a broad network such as the Internet, and can represent a small one such as a LAN or hyperlocal network, it being understood that a network enables communication of data from one computing device to another. Approval determination server 130 can be operatively associated with a computer(s), input device(s) and display(s) 110, 112, 114. Computer, input device and display 110, 1 12, 114 (wherein the foregoing can be singular or plural devices) can contain or be operatively associated with a processor(s), and with memory(ies) which may include software applications. Computer, input device and display 1 10, 112, 114 can comprise a personal computer, a laptop, a tablet, a mobile device such as a smart phone, smart glasses, or a smart watch; it will be appreciated that any device containing or in operative association with a processor(s) and a memory(ies) can serve the purpose of computer and input device 110, 1 12, 114. Device 1 14 can be in operative communication with an added device 1 16 in an offline fashion, i.e., by partial use of network 120 or through direct connection of device 114 with device 116 bypassing more general network 120. Network 120 can permit operative communication of the foregoing functionalities with added devices, functionalities and modules. A rules engine 150 can be in operative communication with network 120 and by extension with added devices and functionalities as shown in FIG. 1. Logical and/or physical partitions, creating tenancies, can be made of devices, functionalities and modules. For example, device 118 can be in communication with network 120, but be partially or wholly excluded from intercommunication with devices 110, 112, 114, and/or 1 16; the reverse can be true, where devices 110, 1 12, 1 14, and/or 116 can be partially or wholly excluded from intercommunication with device 118. By this mechanism, there can be one or multiple tenants served by the methods and systems herein. It is understood that some or all of the foregoing functionalities can be in operative communication via one or more networks, wired or wireless. Each of the foregoing functionalities can be controlled by mechanism of software instructions embodied in a non-transitory computer medium. It will be appreciated that a software resource can be constituted within the functionality of FIG. 1 that can facilitate processing the approval determinations, wherein the software resource can be located within Approval Determination Server, Rules Engine 150, network 120, some or all of the above, or added components.

[0014] In non-limiting embodiments, as seen in FIG. 2 a new travel request 210 can be generated by an employee who wishes to engage in business travel. The travel request 210 can be generated by the employee's supervisor, colleague, or another individual. Such information can include name of traveller, name of company, destination, type of transportation (air, rail, car, water, others), type of accommodations, historical data, purpose of trip, data related to budget for specific employee or employee of a given class in which employee is located, and many more parameters. A traveller profile 220 can be consulted, wherein information associated with the traveller is considered. In embodiments, the travel request can be submitted by a user in conjunction with device 1 10 through network 120 to approval determination server 130, itself in communication with travel database 140 and rules engine 150.

[0015] An approval route(s) can be determined 230. In other words, it can be determined which approvers and/or approval tasks are required in order for a trip approval to be eligible for approval. An approver can be an individual(s) such as the travel requestor's manager, department head, member of accounting team or other financial department, and so on. An approver can also comprise a module or automated service. Put another way, an approval route configures a communications path, which can be dynamically changed depending on unfolding facts and prior determinations, for obtaining the appropriate determination. [0016] An approval task(s) can be determined 240. Such task(s) can comprise budget assessment where it is determined to what extent the traveller, department or other unit is under- budget or over-budget for a given period, among many examples. Another approval task can comprise risk-based duty of care inquiries, including obtaining external input, such as by a governmental, quasi-governmental or private source. Other such tasks can comprise visa review, travel policy compliance, and many others.

[0017] An approval rule(s) can be determined 250. Such rule(s) can comprise logic testing whether an employee's self-selected approval route is in conformance with company policy, to what extent the destination is valid (e.g., is it a "blacklist" destination), and may comprise metarules where a second rule is applied to a first rule, yielding a third, and iteratively onward with added rule generation.

[0018] Returning to FIG. 2, the system can evaluate and execute on information based on or comprising traveller profile information 220, approval route 230, approval tasks 240, and approval rules 250. In addition, external input can be obtained, such as Australia's DFAT (Department of Foreign Affairs and Trade) service that provides updates regarding travel warnings, changes to visa requirements, and other information.

[0019] Approval determinations can be made 280. Put another way it can be decided whether the traveller's request will be approved, denied, or subject to an alternate determination.

[0020] In the event that the traveller's trip request is approved, booking can be unlocked 290. In other words, travel reservations can be authorized, made, and reported to the traveller and relevant others. [0021] The pre-trip approval solution can provide for trip workflow management, before, during and after a journey. The pre-trip approval solution can operate across multiple devices, using a responsive design and operating within a variety of browsers.

[0022] In FIG. 3 is shown an embodiment of an example user interface 300 that can be used in connection with determining approval parameters of potential itineraries. Trip Dashboard 310 is the screen presently displayed. Added UI displays can be available, such as an administration screen 311 , My Trip Requests screen 312, Trip Approvals screen 313, Contacts screen 314, and Reports screen 315. Elements of some or all of the above 310, 311, 312, 313,

314, 315 can be "mixed and matched" as suitable on one or more screen displays, and can be associated with entire screens, cards, or other display options.

[0023] The dashboard can comprise among other elements and modules a set of cards 330, 340, 350. The cards can be populated independently allowing for parallel calls to the underlying data services. Cards shown here are My Trip Requests 330, My Budget 340, and Trip Contacts 350. They may or may not correspond with display screen options 311, 312, 313, 314,

315, which can be seen at left in a navigation panel. A navigation panel can allow the user to shift between the major functional areas within the system. Some screens are also accessible through a card in addition to the navigation pane.

[0024] The activity feed 370 can be displayed when required and can be hidden by the user. The activity feed can show the time based feed for all activities that are in some way related to the logged-in user. Such time-based feed can be ordered on the display by first activity to last activity, actual date and time of activity can be presented on the display, and/or other mechanisms used. An activity within the feed can be clickable and can take the user to the underlying screen. Settings, favourites and notifications can draw attention to activity within the system.

[0025] The system can return to dashboard 310 by default. To access a second level screen a user will be able to click on one of the following: Dashboard card (centre); Navigation item within the menu (left); Activity within the activity feed (right). Again, multiple formats can be used, and positioning of elements comprising the UI can be modified as suitable.

[0026] Card 330, "My Trip Request", can display the desired destination. For example, for purposes of illustration the desired destination here is Cancun, Mexico 331. Card 330 can also comprise a functionality by which a document can be attached to a trip request or for another reason, and can also contain a trip request history related to prior requests.

[0027] Card 340, "My Budget", can display financial information such as that associated with a budget. Data available can include an annual budget for the individual, department, or other unit, an approved expenditure for the above, and remaining budget. Here, the traveller has spent 40% of his or her budget, meaning 60% is remaining. These numbers can be broken down by car, flight, hotel, or other expenditure.

[0028] Card 350, "Trip Contacts", can include a list of approvers proposed by the traveller, required by the employer, a combination of both, or other approvers or contacts. Here contacts include Mary 351, who can be a representative of the travel agent, Joe 352, who can be the traveller's manager, and Kate 353, who is in the Accounting department. Of course, other contacts can be included, with various roles associated with each contact. Messages such as an email can be sent to contacts.

[0029] A trip request progress area 325 can visually display the status of the approvals process. A trip request can be created 320 by the traveller, then submitted 321. An added status can be when a trip request is approved 322. Subsequently, an itinerary can be received 323. and a booking placed 324.

[0030] Quick links 360 can provide ready access to functions via links or other or UI elements that can be actuated. Company travel policies 361 can be made available, as well as Travel Guides 362 for potential destinations and or means of getting there (transportation), and Travel Alerts 363 to advise on potentially negative conditions. A new Travel Request can be created 364.

[0031] Activity feed 370 can display relevant events within the process. Individual items representing activities taken or proposed to be taken can be reflected in items 371-378. These include adding an itinerary to a trip request 378, creating a trip request 377, a comment 376, a cancellation 376, approval by one approver 374, approval by a second approver 373, a rejection 372, an update 371, and adding a file to a trip request 379. There are many more added options that can be put into the activity feed. A travel request identifier 390 can be associated with a travel request.

[0032] In embodiments, cards can be added 380, 381 or removed. In doing so, the trip approval determination process, and visual displays enabling such, can be customized depending on multiple considerations and to suit many scenarios.

[0033] In embodiments parameters include but are not limited to: dynamic, role- based trip dashboard; customizable travel request template; configurable trip approval routine; evaluation against pre-booking parameters; tracking against travel budgets; automated and manual integration with OBT; offline integration from the TMC completing the booking; customizable workflow; reporting; collaboration; single sign on; evaluation against pre-ticketing parameters; client administration. [0034] In addition, a user can request approval for a domestic or international trip, combining budget checks, risk based duty of care destination review via third party links, visa review and check for destination and travel policy compliance in one solution. Embodiments can work in both an offline and online fashion. The invention can be an umbrella across multiple third party online booking tools and can work with any of them subject to API modifications and/or limitations to provide an end to end user experience. The invention integrates with standardizable electronic travel records. Embodiments can run on desktop or mobile devices. Duty of care for employees with integration with external providers of travel alert systems can be made either manually outside the solution or within it using fare-search technology. Approval processes can work for offline travel as well as online (OBT), and integration of online and offline itineraries can be made. Policy and compliance checks on client company policies can be done. TMC Portal - access for TMC for approval information and also through email integration can be done. Provided are capabilities to track travel expenditures against pre-defined budgets. Integration with estimated fare costs to provide indicative airfares for approval purposes can be made within the solution using fare search technology or manually outside it.

[0035] The top level groupings can include: Login & View Dashboard; Request For Travel; Pre-Trip Authorisation; Preparation of Itinerary; Itinerary Authorisation; Booking Placement; Reporting; and Administration.

[0036] A user with a given account can belong to a single tenancy that is associated with a client of a Travel Management Company (TMC). By default the solution can provide a local user directory for a TMC client. The establishment of single sign on (SSO) is an additional on-boarding activity for a client and can warrant an open and standardised interface to the client's own user directory [0037] An individual user may have multiple roles, for instance be a traveller and an approver, as discussed in detail elsewhere.

[0038] A TMC can have a user login and may have an association with one or more clients. A shared login may not be created for a pool of travel consultants. Approver budgets can be entered by the user as part of the administration function and not integrated through client systems.

[0039] Emails with links that would provide the user access to the full system can require a login to the application. The emails configured within the user profile are accessible and up to date.

[0040] The record from an electronic travel record can provide access to actual costs for well defined elements on the Itinerary.

[0041] An electronic record element can be mapped to elements of the Travel Request by adopting standard field types (e.g. Cost of Flight).

[0042] The Travel Request approval code number can be written into the Online Booking Tool (OBT) record for online bookings, which can be useful for creating a correlation between the Travel Request and the Itinerary. This may be done manually or automatically via a one way data transfer from the solution to the OBT using the relevant OBT API's.

[0043] The OBTs can be integrated with an electronic travel record. The pre-trip approval solution can use an electronic travel record as a primary source for obtaining an Itinerary.

[0044] The application can detect when an Itinerary is created or updated in an electronic travel record and correlate this with a Travel Request. [0045] Reporting can be conducted by a TMC or by the client by accessing a reporting view of the operational data. Reporting tools can be provided by a TMC or a client. Configuration system properties can be managed through property files. Authentication into an OBT can be provided at the client level through the use of client level administrative credentials.

[0046] A TMC or an end user client can establish a subscription with a government arm or other mechanism that provides adequate information for use in the pre-trip approval solution for 3rd party travel alerts. A TMC or an end user client can establish a subscription with an international emergency alert service that provides adequate information for use in the pre-trip approval solution for 3rd party travel alerts.

[0047] The solution can include an application (UI), a set of application services and a set of integration services that provide access to external systems. In embodiments the functionality herein can describe a Pre-Trip Workflow. However, it can be extensible to on- Trip and Post- Trip steps.

[0048] Functionality can include the following. The solution can operate as a multi- tenanted software solution that can scale at a low cost by taking advantage of cloud management functionality

[0049] In embodiments, a tenant can be understood on several levels. Generally speaking, a cloud architecture can support multi-tenancy, e.g., where a particular software application supports multiple users. The users can be customers (organizations) or added software applications. As such, a tenancy model permits multiple users to access a single software resource. Multi-tenancy can have an impact on some or all attributes of a cloud architecture and/or functionality. For example, it can have an impact on attributes defining, or defined by, application capabilities related to IaaS (Infrastructure as a Service), PaaS (Platform as a Service), and SaaS (Software as a Service).

[0050] It will be evident, however, that special issues, such as security and confidentiality, are raised where there is a l :n relationship between, for example, a software application in a multi-tenancy environment and an "n" number of users. It will often be desirable to partition one user from another, logically or physically. For example, Company A's access to the application should be controlled in such a manner that there is security and confidentiality of Company A's information vis-a-vis that of Company B, which also can access the software application. In addition, specific individuals at Company A and Company B may be subject to added access controls. For example, a manager at Company A may have broader access to information and greater approval power than a comparable manager at Company B. Or, an individual traveller at Company A may have broader access to flights, hotels, and other travel options that a comparable individual at Company B, thus changing the set of options. There may be interrelationships as well within the company. For example, a traveler at Company A may be associated with an approval route different than a comparable individual due to travel history, destination for the trip, budget history, legal requirements within the jurisdiction, price of the ticket(s), class of travel (budget, business, first), and many more parameters. As but one example, the traveler's approval history may have exceeded a certain threshold, qualitatively or quantitatively, such that the traveler is deemed to have a given weighting assigned certain choices. In other words, an assumption can be made for (or weighting can be assigned to) some or all of the set of information associated with the traveller such that the approval route can be linked with a certain series or responsibility level of approvers. That is to say, if the traveller shows indicia of being a "trusted" traveller based on approval route history, the approval route can be limited to his or her manager alone; if the traveller is not considered a "trusted" one, then the approval route can include another level of approval, added parameters can be included, e.g., travel budget of this traveller, his or her department, or other budget factors, length of service, historical or analytical factors, and many others. In short, the approval tree— i.e., branches defining the approval route ~ can look different based on multiple parameters, including trust associated with the traveller, individual or departmental budget, destination, and many more

t

factors. Further, differential weighting can be given different nodes (such as decision points and/or approvers) on the approval tree. It will be appreciated that an approval route can be considered to traverse various nodes within the organization. Accordingly, an approval route can have a unique configuration. Two approval routes can be compared based on their configurations. As noted above, a node can represent an approver, a decision point, or another functionality. An approval tree can thus be configured to comprise individual(s), decision point(s), and other functionalities. An approval tree can have individuals only, individuals and decision points, decision points only, or have a heterogeneous composition. An approval tree can be considered homogeneous where it has individuals only, decision points only, or functionalities only. An approval tree can be considered homogeneous where it has two or more of the above.

[0051] Further, the tenancy parameters can be taken into consideration. An approval route for an employee based in Australia can by design be different than one based in the United States, which can be different from one in Europe, etc. To the extent the geographic regions are aligned with partitions and/or definitions of the cloud architecture based on region, the different tenancies based on region can be additionally associated with a set of different parameters related to approval of traveller requests. In other words, the approval tree for a tenancy associated with Australia can be different than that in the U.S. [0052] Even so, there may be overlap. In other words, parameters may be assigned with respect to the tenancies in Australia and in the U.S. that are identical. For example, employees in both tenancies can have a presumptive approval route where one of the approvers is the direct manager of the employee. This default feature can, of course, be modified based on multiple factors. Differential weighting can be given; such weighting can correspond to a percent of approval, wherein approval values are calculated, or another type of weighting.

[0053] Returning to the example with two companies, it may be the case then that Company A has a predetermined approval route for employees in Australia but different route for employees in the United States. It may also be the case of course that Company A's approval route is different from that of Company B, again assuming that a single instance of a software application is used to provide the functionality for both. It will be seen, thus, that configuration of the system for intracompany (company A only) and intercompany (companies A and B) utilization of the application can be critical. It can be configured such that each client can operate as a separate tenant. Thus, specific privileges, rules and obligations can be configured for each customer. Client-specific API's, integration functionalities, and scripts can be provided for each client for optimal use within a multi-tenancy environment. In addition, two or more tenancy definitions ~ e.g., by company, by region, or other ~ can be considered together, with differing approval routes or other determinations that can be based on differing rules.

[0054] The solution can include role based access control (RBAC) to provide a level of self-administration for clients. This can be deployed to a cloud and be accessible by appropriate support resources. The log files produced by the application can follow a standard definition to take advantage of the available monitoring and alerting capabilities from the PaaS. [0055] The pre-trip approval solution can cater for different types of workflow (conditional sequences of tasks) within each client.

[0056] The user interface can include use of cards, which can allow for tenant customisation (through card development) as required.

[0057] The solution can use a rules engine to drive the workflow and as such client differences can be configured during on-boarding. Rules can be designed to work with configurable facts. Facts can be easily changed, however rule logic can be programmed for each well-defined form component and in embodiments may not (or may) be configured by the client directly.

[0058] The User Interface can be implemented using HTML5/CSS3. The API that drives the UI can be RESTful (JSON/HTTPS). The API can be designed to cater for the future development of native apps. The solution can include an integration layer that implements SOA patterns to provide abstraction from underlying systems. Data can be represented in multiple formats including Proprietary Data Model (PDM) - specific to underlying systems; and Canonical Data Model (CDM)— common within and across all solution components.

[0059] The pre-trip approval solution can hold information that on its own and in combination would identify a person. Such information can be transferred from client HR systems and stored within the pre-trip approval solution for policy validation and other application functions. PII will be transmitted securely and stored securely. In embodiments, only the minimum required PII will be stored to enable the Pre-Trip Approval workflow to progress.

[0060] The presentation layer is responsible for the presentation of the user interface to users that will fulfil various roles. The product can be developed on HTML5/CSS3 using JSON/HTTPS to communicate with RESTful service (the API) that will be published by the Application Service Layer. The resources that are provided through the API on the Application Service Layer do not necessarily contain user interface specific elements. The resources can be a reflection of the underlying information model, which will be interpreted by the presentation layer and positioned on the HTML page using JavaScript. This approach allows for the API to be used across multiple channels over time without building channel specific semantics into the API. The presentation layer can refer to a set of HTML screens and the corresponding JavaScript that is used to bind the underlying services.

[0061] The wireframes and associated design templates are designed following responsive principles. It will be appreciated that multiple user interfaces, formats and functionalities can be suitable depending on many factors, including user experience. The application can be implemented using a 'Card' layout, which enables each platform to present according to the standard layout and maintain consistency in functionality. Navigation between major system pages can be provided through a retractable navigation bar such as on the left of the application, which can be accessed consistently on the desktop and on a mobile browser.

[0062] Role based access control can be managed by the Application Service Layer. The presentation layer can be responsible for capturing credentials. The Presentation Layer can provide a multi-lingual interface with the option to specify a single language per tenant.

[0063] The following technologies can be used within the Presentation Layer, among others: HTML5/CSS3; JSON/HTTP; Backbone.js; SMTP client email with hyperlink; HTTPS.

[0064] Application Service Layer

[0065] The Application Service Layer can be responsible for managing the services and storage of data within the overall solution. It can provide a RESTful API to the Presentation Layer and can have an interface to the Integration Service Layer. [0066] In addition to providing an API to operate the system, the Application Service Layer can support Administration and Reporting functions through a separate, dedicated User Interface.

[0067] The RESTful service can invoke external services and can be invoked by external services through the integration Service Layer, The Application Service Layer can use the Canonical Data Model (COM) when exchanging information with the Integration Service Layer. The Integration Service Layer can provide abstraction from underlying external systems.

[0068] The Workflow Service is the service that can operate within the Application Service Layer. The Workflow Service can manage the sequence of activities and be supported by Utility and Content Services.

[0069] Utility Services can include:

[0070] Profile Service -— for managing User Profiles

[0071] Notification Service— for managing notification across email, user interface and mobile

[0072] Thread/Collaboration Service— for managing the conversations that occur around a given Travel Request

[0073] Policy Enforcement Service— for managing the rules that are applied to enforce client travel policy

[0074] Audit Service— for managing the capture and retrieval of audit records

[0075] Authentication and Authorisation Services— for managing the user role base access control, including delegated authorization to a client directory.

[0076] Content Services can include:

[0077] Corporate Policy and Preferences— content specific to a client [0078] 3^Γ Party Traveller Information— content from 3rd party providers to be shared with users through the user interface

[0079] Application Service Layer Technologies

[0080] The following technologies can be used within the Application Service Layer, among others:

[0081] Java

[0082] Hibernate

[0083] Spring

[0084] Restful Services

[0085] Web Services (SOAP/HTTPS)

[0086] Rules

[0087] SMTP service (email)

[0088] Relational Database

[0089] Content storage

[0090] Integration Service Layer

[0091] The Integration Service Layer can be responsible for integration with external systems. The Integration Service Layer can provide an abstraction from the 3rd party interfaces, providing a standardized interface to the Application Service Layer.

[0092] Requests placed on the Integration Service Layer can be consistent for each client, with adaptors deployed for disparate systems as required for each new client. The integration layer is designed to manage the integration with at least three separate system categories:

[0093] Integration with Corporate Systems [0094] Traveller Profile Information - combined into a single view with traveller information from other sources

[0095] HR Feeds - providing basic hierarchy information that is used within approval routes. Hierarchy semantics will be provided through a consistent file format for each client.

[0096] Integration with OBTs and electronic travel records.

[0097] Traveller Profile Information - combined into a single view with traveller information from other sources Fares - providing indicative fares between nominated ports.

[0098] Electronic travel record Itineraries - providing a view of the actual itinerary created within an OBT or Global Distribution System (GDS) following the approval of a Travel Request.

[0099] Integration with 3rd Party Content and Travel Alerts

[00100] Travel Alerts - providing industry alerts with a nominated destination filter

[00101] 3rd Party Content - links to external content that will be linked into the solutions dashboard

[00102] Application Service Layer Technologies

[00103] The following technologies among others can be used within the integration Service Layer: Web Services (preferred, but not mandatory); FTP / SFTP; SMTP.

[00104] The ISL can be implemented as a Java service within the Azure tenant group. It can contain standard adaptors for various types of integration already defined. A client specific ISL may be created for each tenant (if required) to allow for customer adaptors and specific security requirements.

[00105] External Systems [00106] The External Systems can be responsible for providing information in a proprietary format to the solution. External systems will integrate with the Integration Service Layer through a variety of technologies.

[00107] An agnostic adaptor can be provided for each well-defined integration point. This agnostic adaptor can define a standard exchange protocol (format and frequency) and can be used by external systems.

[00108] If an external system does not program to the solutions agnostic adaptor for a given integration point, then a custom adaptor can be built to transform information from the external systems proprietary data model (PDM) to the solutions canonical data model (CDM).

[0100] Application Components

[0101] User Interfaces

[0102] The User interface (UI) can be provided as a multi-channel solution accessed through a browser. The design of the solution can cater for future implementation of native applications.

[0103] The User Interface can make use of the API from the Application Service Layer, to retrieve and subsequently update resources through RESTful services.

[0104] Integration with external systems, whether transactional or content based will be directed through the Application Service Layer using the RESTful services.

[0105] An exception to this is where the external content is represented as a link to an external site (e.g. destination travel information). In this case, a new browser window can be started to host the referenced UR1.

[0106] The User Interface can be customized for a TMC or client colour palette for design. [0107] Trip Dashboard

[0108] The Trip Dashboard can be the landing page for users of the pre-trip approval solution. The Trip Dashboard can be presented as a set of 'Cards' stacked according to the style of the browser and the type of device in use.

[0 09] For example, on a desktop browser the cards can be stacked in 3 columns and n rows. On a mobile device the cards will be stacked in a single column. Again, multiple UI's, formats and functionalities can be used.

[0110] The following diagram provides an overview of the structure of the Dashboard.

[0111] Workflow and Pre-Trip Approvals

[0112] The Workflow Service can orchestrate steps for a given Travel Request to be approved. The Workflow Solution can be based on the concept of an Approval Route. An Approval Route can use rules to determine who should be presented with an Approval Task.

[0113] In embodiments, the rules that implement an Approval Route can be implemented in a rules engine. The facts asserted by the rules engine can be taken from the Travel Request and the User Profile.

[0114] Workflow for offline requests can be aligned to mechanisms for transmitting communications, such as email. There will be adequate content in the email sent from the pre- trip approval solution to a Travel Consultant (TC) to perfonn offline bookings. The itinerary that is prepared offline can be loaded into the pre-trip approval solution with an accompanying notification to the traveller when it appears within an electronic travel record. Additional offline measures can be implemented that can integrate online and offline into the full approval route. Some measures may be implemented online, some may be implemented offline, due to security, scalability, customization, budget or other factors.

[0115] Traveller Profiles and Preferences

[0116] The Traveller Profile attributes can be obtained from at least three sources and stored as a single view:

[0117] Client system through an HR Feed

[0118] OBT through an API

[0119] Direct entry into the User Profile component of the pre-trip approval solution application

[0120] The Traveller Profile is designed to be extensible and is implemented as a label / type / value group. The labels used within the Traveller Profile are properties of the system as they can be bound to rules that are used as part of the Workflow Service.

[0121] A client / tenant can nominate a single master data source for profile data. Such nominee can be an HR feed. If this source is not direct entry, under certain circumstances then the values may not be able to be updated through the user interface of the pre-trip approval solution application.

[0122] Travel Request and Collaboration

[0123] The Travel Request can be used through the approval workflow. The Travel Request form can be designed to be configurable for each tenant. Form components represent sets of fields that can be turned on and off for a given tenant. An example of a form component (field set) is 'Billable Trip', which may require a description and billing code.

[0124] Using an extensible form design will allow a TMC or client to commission new form components over time based on client requirements. [0125] As with the Traveller Profile, the attributes of a form are properties of the system as they will be bound to rules that are used as part of the Workflow Service.

[0126] Travel Budgets

[0 27] Travel budgets can be managed at the level of the Approver. A user who has the role of an Approver will be able to nominate an 'Annual Approval Budget'. Any trip that he or she approves can be a burn down against this budget.

[0128] In the case of backup approval, the trip budget can be recorded against the budget of the primary assigned approver. Expenditure can be:

[0129] Planned expenditure requested amounts of the Travel Request Form

[0130] Actual expenditure— actual amounts on the Itinerary

[0131] Where a field within a form component represents an expenditure it can be declared as such to enable the system to collate expenditures in a given Travel Request / Itinerary.

[0132] It will be appreciated that additional Approvers are possible, and various Approval Routes indicated.

[0133] Approval Routes

[0134] The Approval Routes can be defined at the Tenant/Client level. In embodiments, a Traveller as the first step in preparing a Travel Request for approval can select an Approval Route. Thus, the traveller himself or herself can suggest an appropriate approval route. The system can then determine if the requested approval route is, itself, approved. In other words, the approval tree proposed by the traveller can be compared with a tree predetermined by the organization, such as one that may result from predetermined rules including weighting an organization's parameter compared to that of the employee. It can be the case that the organization's rules are designed to trump certain requests by the employee; in other instances, weighting can be used to compare an overall sum of values associated with the employee's request with a sum of values associated with an organization's rules. It can then be determined if sufficient alignment exists and thus the approval route is itself approved, or if variance exists such that the approval route is not approved, and the employee is notified of rejection and asked to modify, or another process is used. A predetermined amount of variance can be set forth such that, if found, the approval route is approved. Such variance parameters and quantities (or qualities) can be predetermined, such as "trusted" nature of the traveller based on for example history, budget history of the department or manager, amount of budget left for a given period, destination, and many other factors. Weighting can be assigned to different parameters in the overall calculations.

[0135] As but one example, if remaining travel budget does not exceed a predetermined quantity or percentage, then the system can appoint an added individual as a second, e.g., higher-level approval requirement. Also, in such circumstances the system can designate a further approval by an individual in another region. The system can draw on historical or analytical metrics. For example, in relation to a historical metric, does travel in October by multiple individuals not require added approvals despite budget burn-down because there is annual "retreat" in that month that many individuals attend, so things are not out of the ordinary? Also, in relation to an analytical metric, have fuel prices risen such that travel is relatively more expensive during a certain period, leading to higher than expected travel expenditures, but ones that nonetheless do not warrant adding further layers of approvals?

[0136] Such historical or analytical factors can also influence an approval route configuration beyond simply budgetary influences to such. For example, an organization may have determined that travel to a certain country, while not a country with "elevated risk", does not provide a cost-benefit based on one or more factors such as revenue per sales trip. If this is the case, added approvals may be implemented. Many potential historical and current analytical metrics can be used.

[0137] In addition, an approval route can change when a destination is selected that is considered to exceed a certain risk-level. Thus, in addition to the initial approval route, there can be added approvals required such as those associated with human resources department approval, occupational health and safety approval, and security approval.

[0138] Alternatively, an approval route can be put in place solely depending on the organization's predetermined preferences without relation to what the traveller wishes. In other words, it may not be the customer that proposed an approval route; it may be the organization that establishes it. There may then be options for the traveller to question or seek to modify organizational preferences/requirements, such as for certain destinations, length of trip, type/class of seating, and many more parameters. In other words, two approval routes can be consdered. The first approval route can be requested by the employee, and can comprise one approval parameter such as which nodes, relationships, or activities are to comprise part or all of the approval route. In addition, the second approval route can be set forth by the organization based on predetermined rules, such as a certain amount of seniority nodes must be gone through (e.g., with reference to position, within the organization, of a given approver), risk assessment of the destination, factors related to budget for the employee, manager or department, price of ticket(s), class of travel, and many more. These and other parameters can be applied in other circumstances as well. The system can determine to what extent the first approval route and second approval route match, and/or components thereof. Rules can be applied to result in which approval route is then made available to the employee. Rules can include when the organization's rules trump traveler preference (or vice versa), what parameter or attribute from each of the first or second route can be weighted and how to use these in determining the outcome, and many other mechanisms.

[0139] An Approval Route identifies the number of approvers that are required and the policy checks to be applied to the Travel Request.

[0140] The Approval Route can be implemented using a rules engine and can use the Travel Request Form and the Traveller Profile to obtain facts for assertion.

[0141] In embodiments, a tenant (e.g., a customer) can have a specific approval route associated with it.

[0142] Reports

[0143] System productivity reports can be provided as cards on the dashboard. A standard set of reports can be provided with the launch product. Reports can have a summary card and a drill down to the actual report data (tabular).

[0144] To support reporting the pre-trip approval solution data can be exported to the TMC or client data warehouse for reporting.

[0145] Application Services. Utility services can be built as loosely coupled components to allow for migration to enterprise services from a 'core¹.

[0146] Profile Service

[0147] The Profile Service can manage a single view of the Traveller Profile for the purpose of Pre Trip Approval. Other components of the PTA Application can be abstracted from the various sources of profile data through this service. [0148] The Profile Service can interact with the Integration Service Layer to obtain profile data from external systems, either through a request or as an unsolicited event containing data.

[0149] Notification

[0150] The Notification Service can manage the distribution of notifications to Travellers, Approvers, TMCs and Administrators are various levels.

[0151] Notifications can take the following form, among others: Emails; Emails with hyperlinks; Application notifications; Device notifications. Many other forms of notifications can be used.

[0152] The Notification Service can implement a defined Notification Scheme that can be configured for each Tenant. A Notification Scheme can define when and how notification should be sent to each system role.

[0153] Thread/Collaboration Service

[0154] The Thread/Collaboration Service can manage a dialogue that occurs between observers of a Travel Request. The dialogue can be implemented as a posting mechanism against the Travel Request with all participants able to view and respond to posts.

[0155] Policy Enforcement Service

[0156] The Policy Enforcement Service can manage the evaluation of business rules in the context of Travel Request approvals and Itinerary (Pre-Ticketing) approvals.

[0157] Business rules can be associated with an Approval Route and can be applied as the Travel Request form is being completed and after any change not initiated through the user interface. [0158] Rules can be defined in the DRL language and asserted through a rules engine, among various methods.

[0159] Rules can be managed as discrete units with logic (DRL) and facts (data input). Rules can be associated with Form Components within the Travel Request Form and can return an internationalised dialogue for display on the screen (in context).

[0160] A full copy of a client's policy can also be added to the 3rd party content store and made available through a defined card on the dashboard.

[0161] Policies can be implemented as rules that are asserted at the following times, among others:

[0162] When submitting a Travel Request Form for approval

[0163] When confirming a prepared Itinerary (pre-ticketing)

[0164] The rules that make up a policy can be composed of the following, among others:

[0165] Logic— programmed into the rule during product development

[0166] System Entities (Trip Request, Itinerary, User Profile)— data available through the pre-trip approval solution

[0167] Reference Data (e.g. blacklist destinations) configurable through reference data management

[0168] Audit Service

[0169] The Audit Service can manage the generation and capture of auditable actions within the application. Auditable actions can exist at least two levels:

[0170] User Activity— changes to the form, conversations, document upload, and others. [0171] System Activity evaluation of rules, timing out of workflow tasks, and others.

[0172] Authentication and Authorisation Service

[0173] The Authentication and Authorisation Service manages the login and role based access control for the application. The authentication can be provided through the Azure Active Directory Service, among other services.

[0174] Authorisation can be managed through simple role based access control (RBAC).

[0175] The roles can include the following without limitation:

[0176] Traveller - ability to submit Travel Requests and track their progress

[0177] Approver - ability to approve Travel Requests and track their progress

[0178] TMC - ability to participate in Travel Request processing through the presentation of tasks to create bookings

[0179] Administrator - systems administration.

[0180] Reporting module. A reporting module can be established that obtains information and develops reports thereon.

[0181] Access to the system can be controlled through authentication and authorisation. To support single click authorisations through email links a service can be provided outside of the pre-trip approval solution will capture the click from the email (embedded URL) and then generate an event into the pre-trip approval solution to change the Trip Request status.

[0182] Integration

[0183] Corporate Systems [0184] Integration can be required with Corporate Systems for the following functions:

[0185] HR Feeds providing profile data for employees

[0186] Employee Login Details - security credentials used for authentication

[0187] For HR Feeds, integration can be achieved through one of multiple integration patterns depending on the client and their ability to support integration.

[0188] The anticipated patterns include but are not limited to:

[0189] Scheduled Web Service invocation - Client Specific ISL conducts a synchronous Web Service call on the client system(s)

[0190] FTP Standard Receiver - Client Specific ISL receives a file from the client systems

[0191] FTP Custom Receiver - Standard (Client Agnostic) Event Socket Laboratory (ESL) or other module receives a file from the client systems

[0192] Web Service Receiver - The pre-trip approval solution ISL offers an API for integration to the client systems

[0193] Integrations will be secured appropriately.

[0194] Travel Alerts and 3rd Party Content

[0195] Travel Alerts and 3rd Party Content cater for the externally generated content that is relevant to the travellers. Information can be consumed through the ISL, with adaptors being created for each external source.

[0196] As an example, the DFAT services within Australia provide destination based updates with regards to travel warning and changes to visa requirements. This is a public data service that will be routed appropriately to the dashboard for travellers given a destination match. [0197] Information received via an integrated source can be directed to a Traveller Dashboard.

[0198] 3rd Party Content can be consumable as content and stored within the pre-trip approval solution. It can also be stored as an external reference (URL).

[0199] A TMC, client or other entity can outsource travel alerts to provide a consistent global coverage. The outsourcing arrangement can include a published set of Itineraries from electronic travel records, and the 3rd party service provider can email those impacted by travel alerts or other relevant content (e.g. visa requirement changes).

[0200] Under certain circumstances, a traveller may receive redundant messages through a direct travel alert (e.g. DFAT via the pre-trip approval solution, and another notification through the existing service provider). To address this issue, an alert can be sent to the pre-trip approval solution which then provides a routing service for the travel alerts and 3rd party content and incorporates this into the activity feed notifications of each traveller individually.

[0201] FIG. 4 shows example application components that can be used in embodiments. User interfaces 410 can be developed using responsive HTML that can work across platforms. A trip dashboard indicator 420 can show a list of relevant trips to a user. Such dashboards can be customized for the traveller, approver, and TMC. Workflow and Trip Approval worfklows 441, 442 can facilitate Pre- Trip Approval activities and functionalities. In addition, On-Trip and Post-Trip activities and functionalities can be used as well. Traveller Profiles 443 and preferences can be included to ensure personal service. They can be entered in the system or obtained through integration from another service. In embodiments it is not the master data store for Traveler Profiles, however under circumstances elements thereof can represent some or all of the master data store. Added application components can include a Travel Requests and Collaboration module 451 , where travel request forms can be configured to include different fields based on employer/company requirements. Travel Budget module 452 can be managed for the employer/company for each individual traveler, or based on another metric. Trip allowances may be applied and cost centres used for allocation. Approval Routes 453 can comprise levels or authorization indicated. Requests for approval can be processed via dashboard and electronic communication or a combination of both. Reports 454 can be provided such as by tiles on a Reporting Dashboard. They can be added over time and can show Pre-Trip Approval volumes and performance. Application Services 430 can comprise reusable utility modules. Administration and Reporting can comprise configuration of budgets, routes, and system settings, and allow reports to be viewed. Abstraction of external systems 480, 481, 482 can be made away from the application by mechanism of an externalized service layer through suitable protocols. For example, integration of Traveller Alerts 480 can be made with modules such as Travel Alerts and 3d Party Content 470; integration of Corporate Systems can be made with modules such as Corporate Profile and Traveller Profile 470; and integration of OBT's 482 can be made with Preferences and Policies and a Booking API 470.

[0202] Integration can be done with multiple OBTs and with electronic travel records, at the following points within the workflow among others.

[0203] After receiving Pre-Trip Approval for a Travel Request the content of the request can be used to create a booking within the OBT. After the creation of an Itinerary with the OBT, the Itinerary can be retrieved from an electronic travel record. Integration with the OBT can occur through the provided API of each OBT. A secure VPN, or an equivalent level of reliable and secure network connectivity, can be established for each OBT. [0204] Authentication into an OBT can be available at the client level or at the traveller level using suitable applications. To authenticate at the traveller level could require added overhead per client (per traveller) and as such client level authentication may be considered; however, an authentication mechanism can be considered based on individual circumstances. Each client can provide tokens during on-boarding. Further, integration with an electronic travel record can occur through an electronic travel record Web Services.

[0205] In embodiments, the pre-trip approval solution can support maintenance of business rules and other configurable elements without the need for a server restart. This can be achieved through a dynamic configuration management framework.

[0206] The solution design can be extensible in the following areas among others.

[0207] For example, the cards on the dashboard may be configured for each client where that client has developed custom cards. The card design paradigm provides a consistent experience across multiple different device types (e.g. desktop browser vs mobile browser can stack cards differently). Additional cards can be programmed at a low cost and added to the pre- trip approval solution to be configured for client.

[0208] In addition, Approval Routes can provide an extension point that will cater for different approval workflow implementation patterns for each client.

[0209] Further, a Travel Request Form can have a section for identity and trip basics, and the remainder of the form can be composed of configuration form components. Additional form components can be added to the pre-trip approval solution through product development and configured for clients.

[0210] In embodiments, an architectural deployment can be seen in FIG. 5. User Interface client 560 can be in operative communication with a load balancing functionality 550, itself in operative communication with a server, including appropriate cache capacity and persistence. An additional server(s) 525 can be used. Further, server 520 can be in operative communication with an Integration Services Layer (540), itself in operative communication with capabilities for obtaining, processing and storing electronic travel records, online booking tools, travel alerts and standard HR feeds 545. Server 520 can also be in operative communication with a client specific ISL 530, itself in operative communication with client systems such as custom HR feeds 535. In addition, an authentication module can assist with functionalities associated with server 520 and other components. Configuration management 510 can assist with managing and coordinating distributed applications. Authentication modules 515 can be used. It will be readily understood that added architectures, logical and physical, can be implemented and the example architecture in FIG. 5 is one of multiple ones that can be used.

[0211] There can be an ISL 530 for each tenant. In addition, there can be a common ISL for one or more tenants. Adaptors for the ISL can be developed to enable operative communication with an external functionality. In embodiments, an ISL can interface between and among one or more TCs, one or more OBTs, and Travel Alert Providers. The ISL can exist within an auto-scaling group such as with a minimum of one VM (virtual machine) within a designated zone. This configuration can provide a level of availability that is adequate based on usage patterns. A load balancing mechanism can be used. Client-specific ISLs can be provided. These can establish for each client custom implementation of independent security measures. For example, a client may wish to establish a custom HR feeds or site-to-site VPN. Similar to above, a client-specific ISL can exist within an auto-scaling group such as with a minimum of one VM within a single zone. [0212] Components of the system can be flexibly coupled and may be distributed to achieve the required capacity or separation of client's data into logical groups. The system can comprise a multi-tenanted SaaS based solution that will leverage a platform from a cloud service provider. The strategy for scale can be to create additional nodes within the platform to hold additional clients with each client representing a tenant of the system. On demand capacity that is available through cloud service providers can allow for scaling on-demand.

[0213] It will be appreciated that one tenant— e.g., including but not limited to an employer or another entity— of the system can be partitioned, logically or physically, from another tenant. This can support security, data integrity, or another parameter such as efficiency.

[0214] The utility services within the system can be stateless and can be replicated to support additional load. The solution can leverage the high-availability services of a chosen cloud service provider, with replication at the database level. The solution can be redundant both within a geographical location and across two geographically diverse locations using the available disaster recovery configuration of the cloud service provider. The solution can operate in two separate virtual environments to provide service abstraction and protection from faults caused by external systems. In particular a platform carrying out the functionality herein can be deployed as a utility services and the pre-trip approval solution (Application), and Integration Service Layer (ISL).

[0215] Load balancing can be established to provide fault tolerance through suitable fail over configuration.

[0216] The system can be implemented using lightweight RESTful services carrying JSON payloads that are close to a model that is displayed through HTML. If the concurrent user access increase introduces a delay in speed of service for displayed information, the deployment architecture can allow for distribution of tenants into new virtual environments. This can reduce the number of concurrent requests and subsequent queries placed on a single VM.

[0217] Integration between the pre- trip approval solution and OBT can be provided through synchronous Web Services.

[0218] Information delivery can occur by the following mechanisms among others. Email can be used for travellers, approvers and TMCs. Web Services can be used for OBT transactions initiated by the PTA application. In addition, text-based modes and other forms of electronic communication can be used.

[0219] Both outbound channels can implement a suitable strategy to detect reliable delivery. For email, this can be characterized by the capability of the associated email server. For outbound Web Services this can be characterized by a transaction management framework combined with a suitable retry strategy and fault policy in the case of binding exceptions (i.e. when an external contract changes and it is not possible to bind).

[0220] The solution can implement an authentication and authorisation framework that ensures secure access through username and password and restricted access to system functions through role based access control (RBAC). Users can access the system through a nominated tenancy (client), queries can be inclusive of the tenancy and as such data for one client will not be visible to users of another client unless expressly authorized subject to security and other considerations.

[0221] Roles can bring with them different privileges. For example, a traveller and manager of the traveller can have different privileges. In other words, a manager may be provided with different approval prerogatives than the traveller, such as expanded ones or ones given more deference by the system. Also, a single role can have different privileges. For example, a manager who is also travelling with the employee can be allocated a privilege level different from that if the manager is traveling alone. Even more, added factors can influence the scope of privileges within a role. For example, a manager who has 20% or less of travel budget remaining for a given period for his or her department may be given less latitude within which to approve a request. The same can be true independent of roles, and/or across the board: for example, if 20% or less of travel budget for a given period is remaining, each approval node may be affected thereby regardless of what role with which it may be associated. Still further, one individual can have two or more roles, and the privileges assigned accordingly to the individual can be based on predetermined rules, such as one set of rules trumps the other unless certain conditions apply, each role can be given a certain weight, one role can only be used with certain features (e.g., must be at least one offline approval node), etc. In addition, roles can be modified based on the approvals/rejections obtained. For example, if a manager rejects a request control can pass back to the employee to submit a modified request; alternatively, control can pass to a colleague of the manager for a validation or cancellation of the basis for the rejection. In other words, contents or parameters associated with a rejection or an approval can be associated with the request for further processing. Further, a traveller can be considered the sole approver under certain circumstances, e.g., trip cost does not exceed a threshold; or, the system can determine that a traveller may not be sole approver if certain conditions apply. Still more, there can be relevant relationships between an approval route and a role matrix. For example, an approval route can be modified based on a configuration— or reconfiguration— of roles assigned to the individuals involved. The role matrix can be set for a certain client as a whole, for different divisions of a client, for geographic regions of different clients, and so on. In sum, then, predetermined rules available for many role-based variations and permutations are possible. [0222] Security between the ISL and the externalised systems will be implemented on an as needed basis. Levels of security can include: OBT integration - authenticated integration through a nominated account credential at the Web Service layer; electronic record Integration — a secure VPN into a TMC or other environment; Client HR Data (received)— secure FTP.

[0223] Deployment Architecture

[0224] Technical and Operational Components

[0225] In embodiments, technical features can include without limitation:

[0226] Load Balancer for Web Application

[0227] The pre-trip approval solution Application Server

[0228] Cache

[0229] Persistence

[0230] Application Server

[0231] Cache

[0232] Persistence

[0233] Azure Active Directory

[0234] The pre-trip approval solution Integration Service Layer (ISL)

[0235] Client Specific ISL

[0236] Configuration Management

[0237] Logical Deployment

[0238] This is a highly available topology utilising the data replication available tlirough each of the chosen PaaS components, and ensuring that the data is replicated both across zones within a single region, and to a remote region when required. Applications requiring active-active HA (high-availability) can help ensure that servers will run across at least two zones within the one region; other applications will run in a configuration that ensures that there is always at least one instance running with only minimal interruption.

[0239] Each tenant group can have its own virtual private cloud (VPC) to be established within an appropriate geographical region (i.e. physical or logical region to the tenant group). However, it will be understood that cloud hosting can be maintained on a global basis with one or more regions partitioned therefrom.

[0240] The DR (disaster recovery) solution can be deployed in a separate region and can provide a mirrored topology of production. The DR topology may be a scaled down version of the primary topology and can have nodes disabled where appropriate to reduce total cost.

[0241] Client specific ISL services can be isolated from the primary platform through the use of standard Azure access controls.

[0242] There can be two or more cloud management regions (with at least two zones/data centres) that components of the solution are deployed to:

[0243] Data Centre 1 Primary

[0244] VPC (Virtual Private Cloud) 1 - Primary Tenant Group - the primary instance of the platform operating the pre-trip approval solution Application

[0245] Data Centre 2 - DR

[0246] VPC2— DR The pre-trip approval solution— the DR (secondary) instance of the platform operating

[0247] The pre-trip approval solution application.

[0248] (Assumed Existing) Data Centre 3 -TMC

[0249] TMC Systems - electronic travel record services

[0250] (Assumed Existing) Data Centre (4 to n) - Clients [0251] Client Systems

[0252] Azure, or a similar functionality, allows for the deployment of nodes across data centres in the same region for high availability. It is assumed that Azure can provide as part of the IAAS the replication technology that can be desirable between regions; in embodiments nodes cannot participate in clusters spanning multiple regions.

[0253] The deployment topology of discrete components and associated high availability configuration can be based on the following principles:

[0254] Real-time data replication to a redundant region for low recovery times

[0255] Active-active and load balanced nodes that maintain state

[0256] Mirrored Instance and load balanced nodes for components that do not maintain state

[0257] On-demand instances for scale-out and failover to reduce cost

[0258] The primary and DR ISL VPCs can provide messaging infrastructure as required for client system endpoint integration, which will include cloud to cloud and cloud to premise communications.

[0259] While various details have been set forth in the foregoing description, it will be appreciated that the various aspects of the approval parameter determination process may be practiced without these specific details. For example, for conciseness and clarity selected aspects may have been shown in block diagram form rather than in detail. Some portions of the detailed descriptions provided herein may be presented in terms of instructions that operate on data that is stored in a computer memory. Such descriptions and representations are used by those skilled in the art to describe and convey the substance of their work to others skilled in the art. [0260] Reference to "one aspect," "an aspect," "one embodiment," or "an embodiment" means that a particular method, feature, structure, or characteristic described in connection with the aspect is included in at least one aspect. Thus, appearances of the phrases "in one aspect," "in an aspect," "in one embodiment," or "in an embodiment" in various places throughout the specification are not necessarily all referring to the same aspect. Furthermore, the particular methods, features, structures or characteristics may be combined in any suitable manner in one or more aspects.

[0261] Although various embodiments have been described herein, many modifications, variations, substitutions, changes, and equivalents to those embodiments may be implemented and will occur to those skilled in the art. Also, where materials are disclosed for certain components, other materials may be used. It is therefore to be understood that the foregoing description and the claims are intended to cover all such modifications and variations as falling within the scope of the disclosed embodiments.

[0262] The foregoing detailed description has set forth various embodiments of the devices and/or processes via the use of block diagrams, flowcharts, and/or examples. Insofar as such block diagrams, flowcharts, and/or examples contain one or more functions and/or operations, it will be understood by those within the art that each function and/or operation within such block diagrams, flowcharts, or examples can be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. In one embodiment, several portions of the subject matter described herein may be implemented via Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal processors (DSPs), or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, can be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein are capable of being distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing medium used to actually carry out the distribution. Examples of a signal bearing medium include, but are not limited to, the following: a recordable type medium such as a floppy disk, a hard disk drive, a Compact Disc (CD), a Digital Video Disk (DVD), a digital tape, a computer memory, etc.; and a transmission type medium such as a digital and/or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link (e.g., transmitter, receiver, transmission logic, reception logic, etc.), etc.).

[0263] One skilled in the art will recognize that the herein described methods, systems, components (e.g., operations), devices, objects, and the discussion accompanying them are used as examples for the sake of conceptual clarity and that various configuration modifications are contemplated. Consequently, as used herein, the specific exemplars set forth and the accompanying discussion are intended to be representative of their more general classes. In general, use of any specific exemplar is intended to be representative of its class, and the non- inclusion of specific components (e.g., operations), devices, and objects should not be taken limiting.

[0264] With respect to the use of substantially any plural and/or singular terms herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. The various singular/plural permutations are not expressly set forth herein for sake of clarity.

[0265] The herein described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely exemplary, and that in fact many other architectures may be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being "in operative communication", "operably connected," or the like to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being "operably couplable," to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and/or physically interacting components, and/or wirelessly interactable, and/or wirelessly interacting components, and/or logically interacting, and/or logically interactable components.

[0266] While particular aspects of the present subject matter described herein have been shown and described, it will be apparent to those skilled in the art that, based upon the teachings herein, changes and modifications may be made without departing from the subject matter described herein and its broader aspects and, therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of the subject matter described herein. It will be understood by those within the art that, in general, terms used herein, and especially in the claims, are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "includes but is not limited to," etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present.

[0267] With respect to the claims, those skilled in the art will appreciate that recited operations therein may generally be performed in any order. Also, although various operational flows are presented in a sequence(s), it should be understood that the various operations may be performed in other orders than those which are illustrated, or may be performed concurrently. Examples of such alternate orderings may include overlapping, interleaved, interrupted, reordered, incremental, preparatory, supplemental, simultaneous, reverse, or other variant orderings, unless context dictates otherwise. Furthermore, terms like "responsive to," "related to," or other adjectives are generally not intended to exclude such variants, unless context dictates otherwise.

[0268] Although various embodiments have been described herein, many modifications, variations, substitutions, changes, and equivalents to those embodiments may be implemented and will occur to those skilled in the art. Also, where materials are disclosed for certain components, other materials may be used. It is therefore to be understood that the foregoing description and the claims are intended to cover all such modifications and variations as falling within the scope of the disclosed embodiments. The claims are intended to cover all such modifications and variations.

[0269] In summary, numerous benefits have been described which result from employing the concepts described herein. The foregoing description of the one or more embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or limiting to the precise form disclosed. Modifications or variations are possible in light of the above teachings. The one or more embodiments were chosen and described in order to illustrate principles and practical application to thereby enable one of ordinary skill in the art to utilize the various embodiments and with various modifications as are suited to the particular use contemplated.

Claims

1. A computer-implemented method for determining an approval route within an organization for authorizing a travel request of an employee of the organization, the method comprising: identifying an attribute of a travel request by the employee; identifying a software resource used for facilitating the approval of the travel request; identifying a tenancy relationship between the software resource and the organization; and configuring an approval route, based on: the tenancy relationship between the software resource and the organization, and a predetermined rule for determining a parameter of the approval route.

2. The method of claim 1 , wherein the tenancy relationship is based in part on identifying two geographic regions served by the software resource.

3. The method of claim 3, wherein a predefined approval route for a first geographic region is non-identical to a predefined approval route for a second geographic region.

4. The method of claim 1 , wherein the tenancy relationship is based in part on identifying two organizations served by the software resource.

5. The method of claim 3, wherein a predefined approval route for a first organization is non-identical to a predefined approval route for a second organization.

6. The method of claim 1, wherein the predetermined rule for detennining a parameter of the approval route is based on budget considerations.

7. The method of claim 6, wherein the budget considerations relate to whether a

predetermined percentage or amount of the budget in connection with a time period has been exceeded.

8. The method of claim 1 , wherein the predetermined rule for determining a parameter of the approval route is based on a risk assessment of the destination of the travel request.

9 The method of claim 1 , wherein the predetermined rule for determining a parameter of the approval route is based on seniority of an approver within the approval route.

10. The method of claim 1 , wherein the predetermined rule for determining a parameter of the approval route is based on a role associated with an approver.

11. The method of claim 11 , wherein the approver is associated with two roles.

12. The method of claim 1 , wherein the predetermined rule for determining a parameter of the approval route is associated with a trust level accorded the employee based on objective metrics derived from past requests by the employee.

13. The method of claim 1 , wherein the predetermined rule for determining a parameter of the approval route includes an offline communication or action associated with the approval process.

14. A computer-implemented method for determining an approval route within an organization for authorizing a travel request of an employee of the organization, the method comprising: identifying the attributes of a travel request from the employee; receiving a first approval route requested by the employee; identifying a second approval route based on predetermined rules set by the organization; comparing the first and second approval routes; and identifying the similarities or differences between the first and second approval routes.

15. The method of claim 14, wherein, based on identifying the similarities or differences between the first and second approval routes, the organization establishes an authorized approval route for this travel request.

16. The method of claim 15, wherein differential weighting is accorded elements of the employee's request and the organization's predetermined rules.

17. A computer-implemented method for determining an approval route within an organization for authorizing a travel request of an employee of the organization, the method comprising: identifying an attribute of a travel request by the employee; identifying a first approver associated with the approval route; identifying a second approver associated with the approval route, wherein the second individual is at an organizational level higher than the first individual; and making an approval determination based in part on whether a travel budget for a specified period has been exceeded.