System Architecture Overview for the Mobile App Flow:

This document explains the end-to-end architecture of the Employee Experience flow covering the functional areas of User management and EmpApp(Scheduling). It focuses exclusively on how the Employee Mobile App interacts with backend services for authentication, employee data retrieval, scheduling, and notifications.

A. High-Level System Overview (Employee Experience)

The Employee Mobile App communicates with several backend services to authenticate users, fetch employee data, retrieve schedules, process shift information, and deliver notifications.

Key Components Involved:

Core Service

• ETS – Central business platform that stores employee records, trip data, shift details, scheduling outputs, and all operational business logic.

Microservices

• EmpExp – Employee lifecycle validation microservice.
   Handles employee master data validation, activation status, and eligibility checks.
  
  

• Schedule Service – Microservice responsible for roster, shift, and schedule management.
   Processes shift master data and synchronizes validated schedule info into ETS.

Data Sync – Used for bulk data ingestion of employee and shift data from external systems (HRMS).

Authentication & Communication

• Account Server – Authentication system used for login, OTP, and token generation.
   Keeps user identity (email/mobile/login status) in sync with ETS.
  
  

• Communication Server – Manages outbound messages (SMS/Email/Push) through configured channels.
  
  

• Identity Provider (IdP) – Used for SSO login where the client organization has enabled Single Sign-On.

B.Mobile App – Technical Process Flow

1️. User Login Initiation (Mobile App → Account Server)

• The Mobile App is the entry point for end users.
  
  

• When a user opens the app and enters their credentials (eg. email/Mobile Number/employee ID and password/OTP):
  
  

  • The app sends a login request to the Mobile App Backend Server via secure HTTPS.
    
    

• The Mobile App Backend Server validates this by calling the Account Server.
  
  

Flow:

Mobile App → Mobile App Backend Server → Account Server

Purpose:

• Account Server authenticates the user credentials.
  
  

• It verifies the user’s existence, password/OTP validity
  
  

• On success, it issues an access token / session ID.

Response:

• Account Server → Mobile App Backend Server → Mobile App
  
  

• The mobile app stores the token for subsequent API calls.

2️. Fetching Core Employee Data (EmpExp & Data Sync involvement)

Once the user is authenticated, the app requests the user’s profile and related data (e.g., employee details, shifts, schedules, etc.).

Flow:

Mobile App → Mobile App Backend Server → ETS (Core Service)

However, before ETS can serve this data, it relies on EmpExp and Data Sync to ensure the latest employee master data is available.

3. Employee Data Preparation via EmpExp Microservice

• EmpExp is a microservice that manages all employee lifecycle and validation logic.
  
  

• It ensures that the employee exists, is active, and the data is up-to-date.
  
  

• It interacts with Data Sync, which brings data from external sources like HRMS.
  
  

Flow:

Data Sync → EmpExp → ETS

Purpose:

• Data Sync fetches or receives employee data from:
  
  

  • Manual Sync (CSV upload)
    
    

  • API (direct HRMS connection)
    
    

  • SFTP (scheduled file transfer)
    
    

• EmpExp validates and transforms this data before sending it to ETS.
  
  

• This ensures ETS always has the correct employee metadata when the user logs in.

Once employee details are updated in ETS,

ETS synchronizes key identity fields (email, mobile, activation status) back to the Account Server to keep authentication records consistent.

ETS → Account Server

4️. Core Business and Shift Data Retrieval (ETS and Schedule Service)

Once the user is authenticated and employee data verified, the Mobile App Backend Server retrieves both core and schedule-related information from ETS and Schedule Service.

Flow:

Mobile App Backend Server → ETS ↔ Schedule Service

Purpose:

• ETS acts as the core platform holding business logic, employee records, trips, and service configurations.
  
  

• Schedule Service is a microservice specialized for managing shift and roster data.
  
  

  • It receives shift data from Data Sync (via manual uploads, API, or SFTP).
    
    

  • Validates, transforms, and standardizes the shift information.
    
    

  • Pushes validated shift data to ETS so that schedules are always aligned with employee details maintained by EmpExp.
    
    

• When the user requests their dashboard or shift data, ETS and Schedule Service jointly serve the most recent and validated information.

Response:

ETS / Schedule Service → Mobile App Backend Server → Mobile App

The user can now view their current schedules, bookings, and related notifications.

5️. Scheduling Operations (Schedule Service Microservice)

When the user interacts with scheduling features (e.g., viewing upcoming shifts or selecting preferred schedules), the Schedule Service microservice handles those operations.

Flow:

Data Sync → Schedule Service ↔ ETS ↔ Mobile App Backend Server → Mobile App

Purpose:

• Data Sync provides schedule and shift master data from multiple sources:
  
  

  • Manual Sync (CSV upload)
    
    

  • API (direct HRMS connection)
    
    

  • SFTP (scheduled file transfer)
    
    

• Schedule Service processes this incoming data, performs necessary validations, and updates ETS with approved shift information.

When the schedules have been modified:

• Schedule Service pulls the shift data from ETS.
  
  

• Applies scheduling rules and ensures that the changes made by the admin or transport team are reflected correctly.
  
  

• Syncs the validated data back to ETS to maintain consistency across the system.

7️. Data Sync Updates (Employee and Schedule Data)

Data Sync continuously or manually ingests bulk data for both employees and shifts from different sources.

Flow:

Manual / API / SFTP → Data Sync

  → EmpExp → ETS  (for Employee Data)

  → Schedule Service → ETS  (for Schedule Data)

Purpose:

• API and SFTP modes run automatically on scheduled intervals to keep data synchronized with external systems.
  
  

• Manual Sync is user-initiated and used for on-demand uploads or corrections — it does not run periodically.
  
  

• After validation by EmpExp and Schedule Service, the clean data is stored in ETS and made available to the mobile application during subsequent API calls.

8.Notifications & Communication (Communication Server)

Whenever an event occurs (such as login, trip confirmation, or shift assignment), ETS or other microservices (like Schedule Service or EmpExp) send a communication request to the Communication Server.

Flow:

ETS / Schedule Service / EmpExp → Communication Server → Channels

Purpose:

• The Communication Server acts as a centralized gateway that manages and routes all outbound communications generated by the system.
  
  

• It determines the appropriate message format, channel, and recipient before sending the communication.
  
  

Channels & Third-Party Vendors:

• AWS → For sending system-generated emails.
  
  

• Value First → For sending SMS notifications.
  
  

• FCM (Firebase Cloud Messaging Platform) → For sending in-app push notifications to mobile users.

C. Single Sign-On (SSO) Process Flow

1️. User enters URL

Since the user is not yet authenticated, MoveInSync starts the SSO authentication process.

2️. MoveInSync passes control to the Client’s Identity Provider

• MoveInSync identifies that the client (organization) uses SSO login.
  
  

• It redirects the user to the Client’s Identity Provider (IdP).
  
  

• The redirect includes OAuth token request containing MoveInSync’s information.
  
  

3️.  IdP checks if the user is already logged in

• The Identity Provider checks if the user already has an active session:
  
  

  • If already logged in: the IdP skips the login screen and proceeds to step 5.
    
    

  • If not logged in: the IdP shows its login page.

4️. User enters credentials on the Identity Provider login page

• The user logs in using their organization credentials
  
  

• The IdP verifies these credentials internally (not visible to MoveInSync).
  
  

5️. Identity Provider authenticates and alerts MoveInSync

• Once the login is successful, the IdP sends an authentication response (OAuth token) back to MoveInSync (the Service Provider).
  
  

• MoveInSync verifies this token using the shared security certificate or key.
  
  

• This confirms the user’s identity without MoveInSync ever seeing their password.
  
  

6️. MoveInSync launches the portal for the user

• The user is now authenticated within MoveInSync.
  
  

• The portal (or mobile app) is launched with the user’s details and permissions.
  
  

• MoveInSync may issue its own session token for continued access within the app.