Common Questions & Q&A

Every request is saved to the database the moment the resident or staff member submits it. If connectivity drops afterward, staff can re-open the dashboard once the connection returns, all pending work is already persisted. No data is lost because nothing relies on a continuous live connection.

Yes. Access is role-based: staff only see records belonging to their own barangay. Data is stored in a private cloud environment, not on shared public servers. An audit log records every action (who viewed, approved, or modified a record) so administrators can trace any activity after the fact.

Absolutely. The QR code on every issued document links back to the original record in the database. When someone scans the code, they see the true, unaltered details (not whatever a resident may have typed into a PDF editor). This is the core anti-tampering guarantee.

The platform is multi-tenant by design. Each barangay is an isolated tenant with its own staff, settings, and data. Adding more barangays is a matter of onboarding; the architecture scales horizontally and does not degrade as tenants are added.

Every approval and rejection is recorded in the audit log. If a staff member realizes a mistake was made, they can review the full history of the request and (if barangay policy allows) resubmit it for a fresh review cycle. The audit trail remains intact so there is no ambiguity about what happened and why.

The system enforces a single-owner flow. Each request belongs to one staff member at a time, and status-based logic prevents a second approval from being processed on the same record. Once approved or rejected, the status transitions and no duplicate action can occur.

The walk-in track exists for exactly this reason. A resident visits the barangay hall and a staff member encodes the request on their behalf. The finished document goes through the same review, generation, and verification pipeline as any online request; the resident never needs a device or an internet connection.

A barangay admin simply uploads a new .docx template. From that moment on, every new document generated uses the updated version. Previously issued documents retain the template that was active when they were created, so there is a clear version trail and no retroactive mismatch.

Every document carries a QR code that, when scanned, opens a verification page linked to the database record. The verifier sees the original details (name, address, document type, date issued) exactly as they were stored. If any field has been edited in the PDF, the scan reveals the discrepancy.

In seconds. The engine reads a pre-built .docx template, fills in the placeholders from the database record, and compiles a finished PDF. There is no manual typing, no copy-pasting, and no waiting for a staff member to format anything by hand.

A Google Form collects data, and that is where it stops. eSerbisyo goes further in five critical ways:

• Multi-tenant isolation: each barangay has its own protected space; data never leaks across tenants.
• QR verification: every issued document is provably authentic against the database.
• Automatic document generation: filled templates produce finished PDFs without manual work.
• Audit trail: every action is logged, so nothing happens in the dark.
• Role-based access: staff, admins, and residents each see only what they are authorized to see.

Four layers work together to protect resident data:

• Scoped access: staff only see records belonging to their own barangay; cross-tenant visibility is architecturally impossible.
• Encrypted storage: data is encrypted at rest and in transit.
• Audit logging: every read and write is recorded, creating a full accountability chain.
• No cross-tenant leakage: the multi-tenant architecture enforces strict data isolation at the database level.