A step-by-step look at how a request travels through eSerbisyo, how each barangay’s data stays private, and what technology makes it all possible.
Imagine a request as a package traveling along a conveyor belt. Every stop on the belt has a clear purpose, and at each stop the package gets closer to its final form. Here is the full journey:
The same path is followed whether the request started online or at the front desk. No data is re-entered at any step; once the information is captured, it flows automatically through review, generation, and delivery.
Think of eSerbisyo as an apartment building. The platform is the building itself, providing electricity (servers), plumbing (the database), and a front door (the login page). But each barangay lives in its own apartment. Every apartment has its own furniture, its own lock, and its own set of residents. One tenant can never walk into another tenant’s room.
In technical terms, every piece of data in the system (every request, every document, every staff account) is tagged with abarangay ID. When a staff member logs in, the system immediately knows which barangay they belong to, and every database query they trigger is filtered to show only that barangay’s records.
If eSerbisyo is a mall, each barangay has its own store. The mall provides the roof, the electricity, and the parking lot, but every store keeps its own inventory behind its own locked door. No store can reach into another store’s stock.
You do not need a CS degree to understand the tools eSerbisyo uses. Here is a plain-language breakdown of each layer:
The front end is built with React, a popular JavaScript library for building user interfaces. Think of it as the store display window (it is the part of the system that residents and staff interact with). It handles buttons, forms, dashboards, and page navigation.
The back end is the server-side code (the engine running under the hood). It receives requests from the front end, talks to the database, runs the business logic (checking permissions, validating forms, generating PDFs), and sends responses back. It is the kitchen where the meals are prepared; the front end is just the dining table.
The database is a structured storage system (a digital filing cabinet). Every resident record, request, document metadata, and audit log is organized in tables. The database ensures that data is stored reliably, searched quickly, and never lost. Each barangay’s data lives in its own partition of this cabinet, locked away from everyone else.
Uploaded documents (scanned IDs, proof of residency, supporting files) are stored in a dedicated file storage service. This keeps large binary files out of the database itself, just like storing boxes in a warehouse instead of on the front desk. Files are linked to the request record that owns them.
The PDF engine takes a blank .docx template and fills in the request data, producing a finished document. The QR engine then generates a unique code tied to that specific document and stamps it onto the PDF. Together, they act as the automated stamping machine and printer in the barangay office (but faster and never making a mistake).
The authentication layer is the bouncer at the front door. It verifies who you are (authentication) and checks what you are allowed to do (authorization). Residents, staff, admins, and platform admins each have a different keycard (one that opens only the doors meant for them).
Every request passes through a series of statuses (like a package moving through a delivery service). Here is what each stage means:
The request has been submitted and is sitting in the staff review queue. Nobody has acted on it yet. This is the digital equivalent of a form placed in the “to review” tray on a secretary’s desk.
When double approval is enabled for a document type, a staff member’s approval moves the request to this stage instead of directly to “Approved.” The request now awaits final approval from a barangay admin. This ensures a second set of eyes on sensitive documents.
The request has received all required approvals (either a single staff approval, or both staff + admin approval when double approval is enabled). The system now triggers the document generation engine to produce the PDF.
The request has been denied (at either the staff or admin stage). The resident is notified with a reason for the rejection and can submit a corrected request.
For document types that require higher accuracy (e.g., business permits, legal certifications), the barangay admin can enable double approval. When enabled, the flow changes:
The same user cannot act as both the staff approver and the admin approver for the same request. This separation of duties prevents a single person from bypassing the dual-review requirement.
For walk-in requests created by staff, the system skips the staff approval step and sends the request directly to “Pending Admin” for admin review.
Each time a request moves from one status to the next, the system records who made the change and when. This creates a complete audit trail (a history of every action taken on that request), which is essential for accountability and transparency.
Security in eSerbisyo works like a building with multiple floors and multiple keycards. You can only enter the floors your keycard grants access to, and the system enforces this at every door.
Every user in the system is assigned a role. Each role has a clearly defined set of permissions:
Every login creates a session (a temporary, secure connection between the user and the system). Sessions expire after a period of inactivity, forcing the user to log in again. This prevents unauthorized access if someone walks away from a logged-in computer. Passwords are hashed (scrambled into an unreadable form) before being stored, so even a database breach would not expose plain-text passwords.
The most critical security guarantee is that every query is scoped to the logged-in user’s barangay. When a staff member loads the request dashboard, the system does not fetch all requests and then filter them (it asks the database only for requests belonging to that specific barangay). This means there is no code path that could accidentally return another barangay’s data. The isolation is built into the data layer itself, not bolted on afterwards.