When something goes wrong in a project, the cause is often a small decision made in a hurry, either before or during fieldwork. Here are the practices we recommend most often, in the order you meet them. Where it helps, we have linked the documentation page with the detailed steps, so you can go deeper when you are ready to set things up.
Prepare the project properly
Use GeoPackage for survey data
Every layer surveyors will edit should be a GeoPackage. Mergin Maps merges changes in GeoPackage files feature by feature. With formats such as Shapefile it cannot detect what others changed, so one person's file overwrites another's and the loser ends up in a conflict file.
One GeoPackage per survey layer
Adding a table to a GeoPackage that people are already synchronising can produce conflicting copies. Create a new file for each survey layer instead: trees.gpkg, hedges.gpkg. Our QGIS Project Preparation guide collects more layer tips like this one and is a good page to have open while you build the project.
Plan the data model before fieldwork
Decide field types, relationships and constraints before anything is deployed: text for names and codes, integer for counts, decimal for measurements, date or date and time for timestamps. Types are the hardest thing to change once devices hold the project.
Add spare fields before you start
Add a few extra fields you do not need yet (text, integer, decimal, date) and hide them from the form. When a new question appears mid-season, give one of them an alias and add it to the form. The form changes, the schema does not.
Use UUIDs for relationships
Link related tables, such as multiple photos or repeat inspections, with a uuid() field, never with fid. Feature IDs can change during synchronisation, and a child record would end up attached to the wrong parent. The same applies to lookup tables surveyors can add to. If you are setting this up for the first time, our Relations page walks through a working example step by step.
Keep files inside the project folder
Survey layers, offline maps and SVG symbols belong inside the project folder, with relative paths set in project properties. A layer that points to your D: drive works on your computer and shows up as missing on every phone.
Design for the person in the field
Design forms for field use
Use Value Map or Value Relation lists instead of free text, Date and Time and Checkbox widgets, sensible default values, tabs and groups and conditional visibility for fields that only apply sometimes. Mark required fields Not null and tick Enforce constraint where a bad value must not be saved. The description you write is what the surveyor reads when the form refuses, so make it a helpful one. There is more on writing good ones in our Constraints documentation.
Use Mergin Maps variables
@mm_username and @mm_user_email record who created or edited a feature. uuid() and now() give stable IDs and timestamps, and @position_horizontal_accuracy stores the GPS accuracy at capture. Set them as default values rather than asking for them. You will find the full list, along with a few we have not mentioned here, on our Variables page.
Remove fields from the form, not the table
If a field is not needed, take it off the form layout. Deleting it from the GeoPackage is a schema change, while hiding it is not. The same goes for renaming: change the alias and leave the field name alone.
Use appropriate user permissions
Surveyors need the Editor role. They can edit features but not the project or the schema. Writer is for whoever maintains the project in QGIS. Readers do not count as contributors, so you can have as many as you like and add stakeholders to follow the project as it grows. We covered this in more depth in Best practices for user management, and the Permissions page has the full breakdown of each role.
Prepare mobile devices for fieldwork
Allow location access
Mergin Maps needs location enabled and permission to use it, or the position marker, position variables and GPS capture will not work. Position tracking records in the background, so location access should not be limited to when the app is on screen.
Allow camera location tags
To read coordinates or direction from a photo's EXIF metadata, the camera also needs location permission and location tags switched on. On Android that is Camera settings ❯ Location tags. On iOS it is Settings ❯ Privacy ❯ Location Services ❯ Camera. Resized photos keep their EXIF data. Once the permissions are sorted, our Geotagging page shows how to pull that metadata straight into your form fields.
Check GPS accuracy when it matters
Getting a position is easy. Getting one you can trust takes a moment longer. Set the accuracy threshold in the app's settings to what the survey needs (10 m by default) and wait for the GPS button to turn green before capturing. Connect an external GNSS receiver when a phone cannot deliver the required accuracy.
Test the project before deployment
On a real phone, capture a feature in every layer, take a photo, try to save a form that should fail, and synchronise. For an offline survey, repeat with the internet switched off and check that the background map covers the area at a useful zoom. Projects cannot be downloaded without a connection, so download before leaving coverage.
Keep projects easy to synchronise
Synchronise at sensible points
Synchronise before leaving, whenever there is signal during the day, and once more on return. Local changes under More shows what is waiting, and Automatically sync changes handles it for teams in coverage. Never remove a project from a device before it has synchronised. Those edits exist nowhere else.
Prepare background maps for offline use
XYZ, WMS and WMTS layers need a connection. Generate tiles in QGIS (Make available offline for vector tiles, Generate XYZ tiles for rasters), limit them to the survey area and the zoom levels people need, save them in the project folder and check the coverage in the app. Our Background Maps guide takes you through each of these options, from free online basemaps to generating your own tiles.
Control photo sizes
Phones can produce images of 10 MB or more, and a season of them stops the project fitting on devices. Set the photo quality in Project Properties ❯ Mergin Maps. High keeps enough detail for most inspections at a fraction of the size.
Organise photo storage
Store photos in a dedicated project folder and, if useful, name them by feature or user. It keeps the project tidy and makes selective sync possible.
Consider selective synchronisation
Selective sync keeps photos on the device that took them and on the server, while other devices download only the features. Point it at the photo folder when nobody in the field needs everyone else's pictures. The Selective Synchronisation page has a worked example of two surveyors sharing a project this way.
Keep projects manageable
Leave out background data nobody uses and keep the project under 8 GB, or downloads slow down and some devices cannot fit it. Projects naturally grow over a busy season, so if yours is already past that, our support tip on what to do if your project is too big explains how to refresh it without losing anything.
Be careful when changing an active project
Avoid schema changes during a survey
Form changes (aliases, widgets, constraints, defaults, symbology) are safe and reach surveyors at their next sync. Adding, deleting or retyping a field restructures the GeoPackage, and a device still editing the old structure can lose its features. If it is unavoidable, follow the steps in How to Deploy Revised Projects: everyone synchronises, the project is removed from every device, the change is synchronised, and every device downloads it fresh.
Review changes before syncing from QGIS
Read the project status before pressing Sync: pending changes, warnings about GeoPackage restructuring and validations such as missing layers. View changes shows what will be uploaded, and Reset changes discards edits you did not mean to make. If data does go missing after a sync, it is usually still on the device. How to Recover Missing Data shows you where to look and how to get it back.
If you have questions, we're here to help
Most of this is a decision made once, when the project is created, plus a habit or two in the field. The reward is a project that synchronises without surprises, fits on devices and produces data you can trust when the season is over.
If anything here raises a question about your own project, get in touch through a support ticket or join the conversation in our community forum, where our team and other users are happy to help. And if there is something you wish Mergin Maps did differently, let us know on the Wishlist.