Project Roles

The project considers 5 different roles that users can have in order for the workflow of a travel request application to be completed successfully:

• Applicant: Most basic role.
  • Can create travel request applications. Require authorizations by N2 and N1 authorizers.
  • Upload expenses vouchers to validate expenses.
• N2 Authorizer: Second-Level autharization role.
  • Can create travel request applications. Requires authorization by N1 authorizers.
  • Gives preliminary authorization to applicant travel request applications.
  • Upload expenses vouchers to validate expenses.
• N1 Authorizer: First-Level authorization role.
  • Can create travel request applications. Requires no authorization.
  • Upload expenses vouchers to validate expenses.
• Travel Agent: Flight and hotel reservation role.
  • Mark hotel as reserved.
  • Mark flight as reserved.
• Accounts Payable: Accounting role.
  • Define imposed fee for travel request applications.
  • Validate expense vouchers uploaded for validation.

There exists an extra Administrator role which is in charge of managing the whole application regarding the configuration of new users, editing existing users, and deactivating users. (This is an important note. users cannot be deleted, per se, from the database. Instead, they are deactivated for the relational database not to have any issues of bad references.)

Role Hierarchy

The roles are not necessarily related with any specific hierarchy in mind except for the roles of Applicant, N2 Authorizer, and N1 Authorizer. And the Administrator role being above every role. Beyond that, they are simply considered as different roles. The following diagram shows how this hierarchy could be visualized.

flowchart TB
    subgraph Administration
        Administrator["Administrator"]
    end
    subgraph Users
        direction TB
        subgraph Applicant-Like
            direction TB
            subgraph Authorizers
                direction TB
                N1_Authorizer["N1 Authorizer"]
                N2_Authorizer["N2 Authorizer"]
            end
            Applicant["Applicant"]
        end
        Accounts_Payable["Accounts Payable"]
        Travel_Agent["Travel Agent"]
    end
    Administration --- Users
    N1_Authorizer --- N2_Authorizer
    N2_Authorizer --- Applicant
    Accounts_Payable --- N1_Authorizer

This does mean that the system is limited to expressing a 5-level hierarchy. Specifically related to the Administrator, Accounts Payable, N1 Authorizer, N2 Authorizer and Applicant roles. Considering that the Administrator has control over the entirety of the system, but cannot interface with it as an applicant or as an authorizer. The Accounts Payable role is in charge of validating the entirety of the expenses validations directly with the applicant, regardless of the applicant's role; hence it's placed above all of the applicant-like roles.

The Travel Agent role should not be conceived as being above any specific role, and be regarded more as an adjacent support role in charge of booking the hotels and flights required for the travel request applications.