Multi-user workflow for collaborative site surveys with live feedback from the office

Advanced Use & Customization
1

Hi there,
This is a split-off from the An attempt at a ‘principle description’ of how to structure a multi-user, callable, collaborative site inspection survey - Ask the Community - QField community to avoid cluttering up the thread.

For production use, I need separated roles. Based on my research, this requires PostGIS as the backend — file-based GeoPackages don’t support concurrent multi-user access with granular permissions.

## Roles

Role Responsibilities Database permissions
Administrator Database schema, migrations, user management, backups Full data definition and access control
Data Modeler Designs layers, fields, relations, form layouts; packages the QField project Full read and write on all layers
Architect Creates and uploads floor plans, renderings, and visualizations from the design model Insert and update on media and drawing layers only; no status changes
Field Surveyor Captures site conditions in QField: rooms, outdoor areas, utility connections, photos Insert and update on survey layers; cannot set approval status
Project Lead Reviews submitted data, approves or rejects entries, adds review comments Update on status and review fields; read access on everything

Status values

Every object that goes through the workflow carries a status field with one of the following values:

Status Meaning Set by
modelled Initial state — object has been created from the design model or entered during survey Field Surveyor or Data Modeler
controlled Object has been checked on site against the actual conditions Field Surveyor
improved Object has been corrected or enriched after the control step Field Surveyor
approved Project Lead confirms the data is correct and complete Project Lead
rejected Project Lead flags the data as incorrect or incomplete, requiring rework Project Lead

Change log layer

To track who changed what and when, a dedicated change log layer records every modification is recommended by AI, not if realy needed.
I have seperate discussion running in Versioning / audit trail with PostGIS backend — practical experience? - Advanced Use & Customization - QField community

Field Description
change_id Unique identifier for this change record
building_id (foreign key) Reference to the building this change belongs to
layer_name Which layer was affected (for example “Room” or “Outdoor Area”)
record_id Identifier of the changed record in that layer
field_name Which attribute was modified (for example “size” or “status”)
old_value Value before the change
new_value Value after the change
status Status of the change itself: proposed, approved, rejected
created_by User who made the change
created_at Timestamp of the change
reviewed_by User who reviewed the change (Project Lead)
review_comment Explanation for approval or rejection

Technical implementation

  • PostGIS is required as the database backend. File-based GeoPackages do not support concurrent multi-user access with granular permissions.
  • Database roles control read, insert, update, and delete permissions per layer. Column-level update permissions ensure that only the Project Lead can modify the status field.
  • Form logic in QGIS makes the status field read-only for all roles except Project Lead, using an editable expression that checks the current database login.
  • Audit triggers in PostGIS automatically write to the change log layer on every insert, update, or delete — no application code required.
  • No role selection in the form. The role is determined by the database login and the project context, not by a dropdown in the user interface.
Inspection of 200 Underground Chambers – Feasibility Question
2

Not much to add here besides that:

  1. yes, Geopackage is not directly meant for multi-user escenarios. Although it is just simply a SQLite file with some predefined extensions, you are free to add more tables/views/etc.
  2. Postgres extended with PostGIS is the more general, appropriate and straight forward solution for what you describe here, to my knowledge.
  3. But take into consideration that QFieldCloud (which is also open source and installable on your servers) also has provisions for user management and would give you multi-user collaboration with file based projects (although not with real-time dynamic updates). QFieldCloud would give you at least an starting point for the data manipulation traceability.
  4. Keep in mind that QField (both with wire transfers and with QFieldCloud) allows you to not share some parts of the project, so you can effectively limit access to some of the data for field work and have all the information on QGIS in the desktop.

And just some minor corrections:

Not “required” per se, but very much encouraged!

With Postgres, permissions can be set per row! Even more granular that per layer.

I agree with the rest of the points on “Technical implementation”.