Pre‐Trip Flow - 101-Coconsulting/TC3005B.501 GitHub Wiki
Pre-Trip Flow
The whole objective of the Pre-Trip Flow is for an application to be properly created by the would-be applicant, which can be either an Applicant, an N2 Authorizer, or an N1 Authorizer. All of the aforementioned roles can create an application and their requirements for the pre-trip flow to be completed varies, since they entail different levels of inherent approval.
After an application is properly created by the would-be applicant, all of the required reviews must be approved, then the trip must be quoted by an Accounts Payable role user, and then have the required flights and hotels booked by a Travel Agent role user, if needed.
The following diagram is an extract of the flowchart found in the home wiki page to visually explain the core of the Pre-Trip Flow.
flowchart TB
Application_Created["Application is Created"]
Application_Reviewed["Application is reviewed<br>(as needed)"]
Application_Quoted["Application is<br>quoted for budget"]
Application_Reserved["Application reservations are made (as needed)"]
Application_Created --> Application_Reviewed
Application_Reviewed --> Application_Quoted
Application_Quoted --> Application_Reserved
On authorizations
Whenever an application requires review and authorization by either an N2 Authorizer or an N1 Authorizer, if the application is rejected, it is considered finished, and in case a user still requires to go on the same trip, a brand new travel request application must be created, including the corrections required for the new application to be accepted this time around.
Applicant Application
This is the most common use-case for the project. Where a person with the role of Applicant can generate a travel request application. This is basically all they can do. Generate their travel request applications.
The following diagram simply illustrates the flow between the different actors involved in the approval of a travel request application by an Applicant:
---
config:
theme: dark
look: classic
---
sequenceDiagram
autonumber
box rgb(50, 50, 50) Applicant
actor Applicant
end
box rgb(50, 50, 50) Authorizers
actor N2 Authorizer
actor N1 Authorizer
end
box rgb(50, 50, 50) Support
actor Accounts Payable
actor Travel Agent
end
opt Draft Application
loop As Needed
Applicant ->> Applicant: Saves Draft Application
activate Applicant
end
end
Applicant ->> N2 Authorizer: Submits Finished Application
activate N2 Authorizer
rect darkred
break Rejected
N2 Authorizer -->> Applicant: Rejects First Review
end
end
rect darkgreen
N2 Authorizer ->> N1 Authorizer: Approves First Review
activate N1 Authorizer
deactivate N2 Authorizer
end
rect darkred
break Rejected
N1 Authorizer -->> Applicant: Rejects Second Review
end
end
rect darkgreen
N1 Authorizer ->> Accounts Payable: Approves Second Review
activate Accounts Payable
deactivate N1 Authorizer
end
alt Requires No Hotel or Flight
Accounts Payable ->> Applicant: Attends Request
else Requires Hotel or Flight
Accounts Payable ->> Travel Agent: Attends Request
activate Travel Agent
deactivate Accounts Payable
Travel Agent ->> Applicant: Attends Request
deactivate Travel Agent
deactivate Applicant
end
N2 Authorizer Application
N2 Authorizers can also create travel application requests. This is not their main intended role, but they do have the ability to do so if desired.
The following diagram simply illustrates the flow between the different actors involved in the approval of a travel request application by an N2 Authorizer:
---
config:
theme: dark
look: classic
---
sequenceDiagram
autonumber
box rgb(50, 50, 50) Applicant
actor N2 Authorizer
end
box rgb(50, 50, 50) Authorizers
actor N1 Authorizer
end
box rgb(50, 50, 50) Support
actor Accounts Payable
actor Travel Agent
end
opt Draft Application
loop As Needed
N2 Authorizer ->> N2 Authorizer: Saves Draft Application
activate N2 Authorizer
end
end
N2 Authorizer ->> N1 Authorizer: Submits Finished Application
activate N1 Authorizer
rect darkred
break Rejected
N1 Authorizer -->> N2 Authorizer: Rejects Second Review
end
end
rect darkgreen
N1 Authorizer ->> Accounts Payable: Approves Second Review
activate Accounts Payable
deactivate N1 Authorizer
end
alt Requires No Hotel or Flight
Accounts Payable ->> N2 Authorizer: Attends Request
else Requires Hotel or Flight
Accounts Payable ->> Travel Agent: Attends Request
activate Travel Agent
deactivate Accounts Payable
Travel Agent ->> N2 Authorizer: Attends Request
deactivate Travel Agent
deactivate N2 Authorizer
end
N1 Authorizer Application
N1 Authorizers are meant to be the most important role when it comes to athorizing a travel request application, hence they will require no review process for authorizing the travel request applications they create.
The following diagram simply illustrates the flow between the different actors involved in the approval of a travel request application by an N1 Authorizer:
---
config:
theme: dark
look: classic
---
sequenceDiagram
autonumber
box rgb(50, 50, 50) Applicant
actor N1 Authorizer
end
box rgb(50, 50, 50) Support
actor Accounts Payable
actor Travel Agent
end
opt Draft Application
loop As Needed
N1 Authorizer ->> N1 Authorizer: Saves Draft Application
activate N1 Authorizer
end
end
N1 Authorizer ->> Accounts Payable: Submits Finished Application
activate Accounts Payable
alt Requires No Hotel or Flight
Accounts Payable ->> N1 Authorizer: Attends Request
else Requires Hotel or Flight
Accounts Payable ->> Travel Agent: Attends Request
activate Travel Agent
deactivate Accounts Payable
Travel Agent ->> N1 Authorizer: Attends Request
deactivate Travel Agent
deactivate N1 Authorizer
end