Survey123

Survey123 is a form-based data collection system in the ArcGIS platform. It can be used for simple questionnaires, field inspections, environmental monitoring, asset registers, repeat observations, community surveys and complex forms that combine location, photographs, audio, attachments and structured questions.

For Māori GIS mahi, its value is usually not the form itself. The value is creating a consistent field record that can be checked, mapped, compared over time and connected to the wider kaupapa. A good Survey123 form can help a marae team inspect assets, a taiao team revisit monitoring sites, a whenua trust record access and infrastructure observations, or a restoration project track planting survival. A poor form can collect a large amount of information nobody needs, expose sensitive locations, and create a tidy-looking database that is difficult to interpret later.

Survey123 works best when the questions, access rules, review process and downstream use are designed before collection begins.

Survey123 website: https://survey123.arcgis.com/

Product overview: https://www.esri.com/en-us/arcgis/products/arcgis-survey123/overview

Official documentation: https://doc.arcgis.com/en/survey123/

For a wider comparison with QField, Field Maps and KoboToolbox, start with Field GIS.

Survey123 in 2026

Esri introduced Survey123 Studio and Survey123 Mobile in July 2026. Survey123 Studio is the next-generation desktop authoring application and Survey123 Mobile is the next-generation capture application. Esri describes Studio as the successor to Survey123 Connect and Mobile as the successor to the Survey123 field app.

The transition is still important when choosing how to build a form. Some capabilities available in Survey123 Connect and the field app are not yet available in Studio or Mobile. This includes some advanced authoring, offline basemap and smart-assistant functions. Check the current functionality matrix before committing a project to one app.

What's new: https://doc.arcgis.com/en/survey123/get-started/whatsnewsurvey123.htm

Functionality matrix: https://doc.arcgis.com/en/survey123/get-started/functionality-matrix.htm

A practical approach in 2026 is:

• use the web designer for ordinary forms that can be built visually
• use Survey123 Studio for new advanced forms where its current capability is sufficient
• use Survey123 Connect and the field app where the project still needs a function not yet available in Studio or Mobile
• test the exact authoring and capture combination before training a larger group

Do not assume that a form which works in one Survey123 app will behave identically in every other app.

Form first or map first

Survey123 is strongest when the form is the main part of the workflow. The collector is answering a defined set of questions and location is one part of the record.

Examples include:

• inspecting a water tank and recording condition, capacity, photograph and required action
• revisiting an awa monitoring site and recording the same observations each month
• checking planting survival within a restoration block
• documenting the current condition of a gate, culvert, fence or track
• recording a community response where the questions are more important than editing a map feature

Use ArcGIS Field Maps when people need to work primarily from a map, select existing features, navigate between assets and edit geometry directly.

Many useful projects combine both. A team may maintain authoritative asset geometry in Field Maps and use Survey123 for a detailed inspection form linked to each asset.

What a survey can contain

Survey123 can collect far more than a name and a GPS point. Depending on the authoring and capture application, a form can include:

• single-choice and multiple-choice questions
• text, integer and decimal values
• dates, times and date-time values
• location as a point
• lines and polygons using geotrace and geoshape questions
• photographs and image annotations
• audio
• signatures
• file attachments
• barcodes
• calculations
• required questions and validation constraints
• conditional questions that appear only when relevant
• groups and pages
• repeated sets of questions stored as related records
• values looked up from CSV files or feature layers
• hidden fields for IDs, workflow status and provenance
• calculated values derived from previous answers

Question types: https://doc.arcgis.com/en/survey123/create/main/question-types-overview.htm

The form should still collect only what the project needs. The technical ability to add another question is not a reason to add it.

Start with the kaupapa

Before opening the designer, write down what the survey is meant to support. A useful statement is specific enough that people can tell what belongs in the form and what does not.

For example:

Record repeat observations at agreed awa monitoring sites so the taiao team can compare changes, identify follow-up mahi and retain photographs and notes against a stable site ID.

That statement is more useful than “build an environmental survey”.

Then decide:

1. What decision, action or monitoring programme will use the information?
2. Who is expected to collect it?
3. Who checks it?
4. Who can see the raw submissions?
5. Which fields can be shared more widely?
6. Is any kōrero, location, photograph or personal information sensitive?
7. What needs to be retained as the original observation?
8. What can be derived later in GIS rather than collected in the field?
9. What happens when the project finishes or the person who built the form leaves?
10. What does the collector need to know when there is no mobile coverage?

This is also the point to decide whether Survey123 is the right tool at all.

Build the data model before the screen

A form is a user interface over a dataset. Design the dataset first.

A practical field observation structure might include:

Field	Purpose
observation_id	stable project identifier
site_id	link to the place, asset or monitoring site
observation_type	controlled category
observed_date	when the observation was made
collected_by	collector where required
status	current workflow or condition
notes	short contextual information
photo_required	whether photographic evidence is expected
gps_accuracy_m	device-reported accuracy where useful
geometry_source	GPS, map sketch, existing feature or other method
sensitivity	internal handling category
review_status	new, checked, needs follow-up, rejected
checked_by	reviewer
checked_date	review date
source_method	field observation, instrument, document or another source

Use stable IDs rather than relying only on feature IDs created automatically by ArcGIS. Stable project IDs make joins, exports, repeat visits and long-term migration easier.

Keep raw observation fields separate from later interpretations. If a collector records “water brown after rainfall”, do not overwrite that wording later with “high sediment event”. Store the interpretation separately.

Design for the person holding the phone

A field form should be quick enough to use while standing beside an awa, gate, planting block or building. Long forms often become poor data because collectors rush, skip or guess.

Good form design normally includes:

• a short first page confirming site, collector and date
• controlled lists for repeated categories
• required fields only where a missing value would genuinely make the record unusable
• conditional questions so irrelevant sections stay hidden
• clear choices such as unknown, not observed or not applicable where those are legitimate answers
• short help text where a term could be interpreted in different ways
• a final review section for notes, photographs and follow-up
• enough context that a new collector can use the form without remembering what the designer meant six months earlier

Avoid giant “notes” boxes when the same information can be captured consistently through a few controlled questions. Keep a notes field as well, because the field always finds a way to be more complicated than the form designer expected.

Themes and collection opportunities

The examples below are starting points. They are not standard Māori datasets and should be adapted to the kaupapa, tikanga, authority and actual information needs of the people doing the mahi.

Theme	Example form	Useful collection opportunities
Marae assets	Marae asset inspection	buildings, water tanks, generators, solar, communications, fire equipment, access, kitchens, toilets, storage, maintenance
Marae resilience	Emergency readiness check	water, power, alternate access, assembly areas, communications, supplies, accessibility, operational status
Awa and wetlands	Monitoring site visit	water appearance, flow, bank condition, erosion, rubbish, weeds, photographs, measurements, follow-up
Restoration	Planting survival check	planting block, species, survival, browse damage, pest pressure, weed competition, maintenance, replanting
Biosecurity	Pest or weed observation	species, abundance, extent, life stage, treatment, photograph, revisit date
Whenua management	Whenua inspection	gates, fences, tracks, culverts, drainage, dumping, erosion, access observations, maintenance
Papakāinga investigation	Site visit observations	visible access, terrain observations, service evidence, drainage, photographs, questions for specialists
Hītori and heritage	Field verification record	site reference, source reference, visible evidence, current condition, location confidence, photograph, sensitivity
Ingoa wāhi research	Place-name field check	name variant, source, local reference, candidate location, confidence, reviewer, publishing restriction
Rangatahi mapping	Community field observation	public teaching features, environment, facilities, photographs, simple GPS, reflection
Emergency response	Rapid impact assessment	access, building status, utilities, hazards observed, photographs, immediate action, follow-up
Community engagement	Hui or whānau survey	priorities, comments, consent, demographic information only where justified, optional location

A project may use several forms rather than forcing everything into one large survey.

Example: marae asset inspection

A marae asset form can be kept practical and operational. The form is not the asset-management system by itself. It is the field method for keeping the asset register current.

Useful fields include:

Question	Example
asset_id	MARAE-WATER-003
asset_type	water tank
asset_name	Upper tank
location	existing asset point or GPS check
operational	yes, partly, no, unknown
condition	good, monitor, repair, replace
capacity_or_size	project-defined value
issue_type	leak, corrosion, access, electrical, structural, other
immediate_action	none, isolate, repair, specialist check
photo	current image
notes	field context
public_safe	yes or no for a later public derivative
checked_date	inspection date

Use a repeat where one site visit covers several related components, for example a pump, tank, pipe and valve. Keep the asset itself stable and store each inspection as a dated related record if you want to see change over time.

For a wider marae mapping structure, see Marae GIS and Marae emergency mapping.

Example: awa monitoring

A repeat environmental monitoring form should make comparison over time easier. The site ID is normally more important than collecting a new point every visit.

A useful form might include:

Question	Example use
site_id	stable monitoring site
visit_date	repeat observation date
observer	person or team
rainfall_context	recent rain, dry period, unknown
water_appearance	clear, slightly turbid, turbid, discoloured
flow_observation	low, normal, high, overbank
bank_condition	stable, minor erosion, active erosion
rubbish	none, minor, significant
weed_or_pest	controlled list plus other
measurement_method	visual, meter, sample, other
measurement_value	only where a defined method exists
photo_upstream	repeat viewpoint
photo_downstream	repeat viewpoint
follow_up	none, revisit, maintenance, specialist review
notes	unusual conditions

If the project collects instrument measurements, store the unit and method. A value of “7.4” is not useful in five years if nobody can tell whether it was pH, dissolved oxygen or something else.

See Awa, wetlands, coast and moana for the wider GIS workflow.

Example: restoration and planting

Survey123 works well for repeated checks of restoration blocks because the questions can remain consistent across seasons.

A planting-survival form could collect:

• restoration_block_id
• planting_event_id
• inspection_date
• species or planting mix
• number checked
• number alive
• estimated survival percentage
• browse damage
• drought stress
• weed competition
• pest evidence
• guards or stakes condition
• infill planting required
• photograph
• follow-up date

Use a polygon only when the collector is genuinely defining or updating an area. If the restoration block already exists in GIS, use its stable ID and avoid redrawing it at every visit.

Example: whenua inspection

A Māori land trust or whānau project may use a form for practical condition and access observations.

Possible questions include:

• block or project ID
• visit purpose
• entrance or gate observed
• track condition
• culvert or drainage condition
• fence condition
• stock access observed
• erosion or slips observed
• dumping or rubbish
• visible utilities
• maintenance required
• photograph
• location
• follow-up owner
• review status

Treat the field record as an observation. A visible track does not establish legal access. A fence does not establish a legal boundary. A phone GPS point does not redefine a parcel or Māori Land Court block.

For cadastral and whenua questions, keep Survey123 observations separate from authoritative records from LINZ, Pātaka Whenua, titles, survey plans and other relevant sources.

Example: papakāinga field observations

Survey123 can support a papakāinga investigation by capturing what a project team sees during site visits. It should not turn an early field visit into a fake suitability assessment.

Useful observations include:

• candidate_area_id
• date and visit purpose
• practical vehicle access observed
• visible drainage
• terrain notes
• existing structures
• visible utility infrastructure
• photographs from repeat viewpoints
• unresolved access question
• unresolved services question
• unresolved hazard question
• specialist follow-up required

Use the form to make evidence and unanswered questions visible. Planning, engineering, geotechnical, infrastructure and whenua decisions still require their own evidence and authority.

See the Papakāinga investigation worked example.

Example: hītori and heritage field checking

Historical and cultural research often begins with a document, map or kōrero and later needs a field visit. Survey123 can provide a disciplined way to record what is visible now without turning the field observation into proof of the historical claim.

A useful structure includes:

Field	Purpose
research_record_id	link to the original research record
source_reference	report, page, map or other evidence
visit_date	field date
current_observation	what can be seen now
location_method	GPS, approximate, source-derived, local guidance
location_confidence	project-defined confidence
photo	current condition
interpretation	kept separate from raw observation
checked_by	reviewer
sensitivity	handling restriction
publish_geometry	exact, generalised, none

Do not use a public form for wāhi tapu, urupā, whakapapa-linked locations or other restricted information simply because the software makes publication easy. Public availability of a historical source does not automatically settle whether extracted or combined information should be republished.

Example: rangatahi field mapping

Survey123 can be useful for a structured learning exercise where rangatahi collect observations and see how a form becomes GIS data.

Keep teaching exercises to public or synthetic information. Examples include:

• public facilities
• street trees
• visible stream condition
• litter observations
• public art
• accessibility features
• public recreation assets

A simple form can collect feature type, short observation, photograph, location, accuracy and date. The next step is to map the submissions and discuss what makes a field record reliable, what a coordinate actually means, and why some information should not be public.

Repeats and related records

Repeats let a collector enter the same set of questions several times within one survey. ArcGIS stores repeats as related tables or related layers.

They are useful for:

• several assets inspected during one site visit
• several species observations at one monitoring site
• several photographs or measurements with their own attributes
• household or whānau survey structures where collection is authorised and appropriate
• several maintenance actions against one inspection
• repeated subcomponents such as gates, culverts or tanks

Official guidance: https://doc.arcgis.com/en/survey123/create/main/xlsformrepeats.htm

Think about the relationship before building it. A repeat is not only a visual form control. It changes the data model.

For long-term monitoring, another useful pattern is one stable master record for each site or asset and a separate related observation table containing one row for every visit. This prevents the latest observation from overwriting the previous one.

Conditional logic and validation

The form should prevent avoidable errors while allowing legitimate uncertainty.

Examples include:

• show “describe damage” only when condition is repair or replace
• require a photograph when an issue is classified as significant
• prevent a percentage from being entered below 0 or above 100
• show species details only when a weed or pest is observed
• ask for a follow-up date only when follow-up is required
• warn when GPS accuracy is poorer than the project threshold
• require a reason if a collector changes an existing status

Do not use validation to force a collector to invent certainty. If “unknown” is a real state, include it.

Location is a measurement

Survey123 can record points, lines and polygons. That does not mean every geometry has the same accuracy or authority.

A phone or tablet may use GNSS, cellular, Wi-Fi and other location sources. Device-reported accuracy can change rapidly depending on sky view, hardware and conditions.

For projects where accuracy is important:

• record the reported horizontal accuracy
• define the minimum accuracy required for the task
• consider location averaging
• use a high-accuracy GNSS receiver where the kaupapa requires it
• store whether geometry came from device GPS, an external receiver, a map sketch or an existing GIS feature
• test the actual device and receiver combination before field rollout

Survey123 can extract GPS metadata and can be configured with location accuracy thresholds and quality expressions.

High-accuracy guidance: https://doc.arcgis.com/en/survey123/create/studio/high-accuracy-prep.htm

Geopoint guidance: https://doc.arcgis.com/en/survey123/create/main/geopoints.htm

A coordinate that displays six decimal places is not automatically accurate to six decimal places.

Do not use ordinary field GPS to establish legal boundaries.

Lines and polygons

Geotrace and geoshape questions can collect lines and polygons.

Useful examples include:

• sketching a short erosion extent
• recording the approximate length of damaged fencing
• mapping a planting or weed-control area
• recording an observed access route
• outlining an operational work area

Official guidance: https://doc.arcgis.com/en/survey123/create/main/geotracegeoshape.htm

Keep a distinction between observed geometry and authoritative geometry. A collector sketching a flood impact area is creating an observation. They are not replacing an official flood model or survey plan.

Photographs and attachments

Photographs can be some of the most useful evidence in a field form. They can also expose more information than the collector intended.

A photograph can reveal:

• exact or inferable location
• people
• vehicle registrations
• building interiors
• cultural objects
• written documents
• computer screens
• neighbouring properties
• children
• infrastructure details
• information in image metadata

Before requiring photographs, decide what the photograph is for, who can see it, how long it should be retained and whether a less sensitive image would still meet the need.

Use repeat viewpoints where change over time is important. A photograph taken from approximately the same place and direction each visit is far more useful for monitoring than a folder of unrelated images.

Work offline deliberately

Survey123 can continue collecting forms while disconnected, but the exact offline capability depends on the capture application and the functions used in the form.

Survey123 Mobile and the field app can collect while offline. Functions that depend on online services may not work while disconnected. The older Survey123 field app supports configured offline basemaps. As of the 2026 transition, not every field-app offline-map capability is available in Survey123 Mobile.

General offline guidance: https://doc.arcgis.com/en/survey123/get-started/faqgeneral.htm

Offline basemaps for the field app: https://doc.arcgis.com/en/survey123/create/connect/preparebasemaps.htm

Before sending a team into an area with poor coverage:

1. install and sign in on the actual device
2. download the survey
3. download any required offline map or content
4. put the device into flight mode
5. complete several realistic records
6. capture photographs and location
7. close and reopen the app
8. confirm unsent records remain available
9. reconnect and submit
10. inspect the resulting feature, attachments and related records in ArcGIS Online or Pro

Do the test with the same phone or tablet model the field team will use. A desktop preview is not a field test.

AI in Survey123

Survey123 now includes several different kinds of AI. They should not be treated as one capability.

Esri's current Survey123 AI guidance lists:

• conversational assistance to help design a survey in the web designer
• a translation assistant for survey designs
• AI-powered image analysis, text analysis and audio transcription in the web app, currently described as beta analysis calculations
• separate on-device machine-learning smart assistants in surveys created with Survey123 Connect and used in the Survey123 field app

Official AI guidance: https://doc.arcgis.com/en/survey123/get-started/survey123-ai.htm

AI-assisted survey design

The web designer can use a conversation to help create a survey. This can be useful for generating a first structure such as:

Create a field inspection form for marae water assets. Include asset ID, asset type, operational status, condition, photograph, issue, immediate action, inspection date and follow-up.

Treat the generated form as a draft. Check:

• whether the questions actually match the kaupapa
• whether unnecessary personal information has been added
• whether categories reflect local practice
• whether required fields are genuinely required
• whether choice wording is clear
• whether the schema will still make sense after export
• whether sensitive fields should exist at all

AI can save time building the first version. It should not decide what information an iwi, hapū, marae or trust should collect.

AI translation

Survey123 can assist with translating survey designs. This may help create multilingual forms, but machine translation still needs review by people with appropriate language knowledge and context.

For te reo Māori, review wording for the actual kaupapa, dialect preferences, technical meaning and audience. A technically plausible translation can still be wrong for the people using the form.

Do not treat an AI translation as linguistic authority.

AI image, text and audio analysis

The Survey123 web designer can configure analysis calculations that use AI to extract information from images or text and to transcribe audio.

Potential field uses include:

• extract a candidate asset identifier from a sign or label
• classify free-text maintenance notes into a working category
• transcribe a spoken field note
• extract structured attributes from an image for later checking
• translate a working response into another language
• create a preliminary category from a long text response

These features can reduce repetitive typing, but the source observation should remain available.

A useful AI provenance pattern is:

Field	Purpose
raw_observation	original text or transcription source
ai_output	generated extraction or classification
ai_method	feature or model used
ai_review_status	unchecked, checked, corrected, rejected
ai_reviewed_by	person who reviewed it
ai_reviewed_date	date of review
final_value	accepted value used downstream

Do not overwrite the raw response with the AI result.

Esri states that AI suggestions can be misleading or inaccurate and human judgement should be applied. Image and text extraction can consume ArcGIS credits.

On-device smart assistants

Survey123 Connect and the Survey123 field app support smart assistants for image classification, object detection, annotation and redaction. These use machine-learning models on the device rather than Survey123's online generative AI services.

Smart assistants: https://doc.arcgis.com/en/survey123/create/connect/smartassistants.htm

Possible uses include:

• detecting a defined asset class in an image
• assisting with image annotation
• identifying candidate objects for a structured field
• redacting faces or other detected objects before submission

These functions remain subject to model error. Automated redaction can miss information, so the final image still needs human checking.

The smart-assistant documentation also notes that some built-in technologies may send usage or analytics information to third parties even though image processing itself occurs on the device. Check the current product documentation and organisational settings before using these functions with sensitive material.

AI and Māori information

Before enabling AI against Māori information, ask a separate set of questions from the ordinary “can the software do it?” question.

Consider:

1. What information is being processed?
2. Who has authority or interests in that information?
3. Is the source already public, restricted or held for a particular purpose?
4. Does the AI use create a new inferred category, location or interpretation?
5. Where is the processing occurring?
6. What is retained?
7. What can administrators, vendors or other services access?
8. What is the consequence if the AI output is wrong?
9. Is a person checking the result before it is mapped, reported or acted on?
10. Is the original source retained so the derived result can be challenged later?

Esri states that prompts used by Survey123 AI are not used to train Esri or third-party AI models, are not used to improve Esri or third-party services, and are not stored or shared unless the user gives explicit permission, such as providing feedback. Those product controls are useful, but they do not decide whether a particular Māori dataset should be submitted to the service.

Read Before you use AI with Māori information, AI for Māori GIS and Artificial intelligence and GIS.

Practical AI boundaries

For Māori GIS field work, a useful default is:

• use AI to assist with form drafting, repetitive extraction, transcription and candidate classification
• preserve the original field evidence
• identify AI-derived values clearly
• require human review before important downstream use
• do not let AI infer or publish sensitive cultural meaning
• do not let an AI-generated coordinate replace a real location source
• do not use AI alone to determine legal status, land rights, cultural authority, compliance, safety or another high-consequence decision

AI can help process the record. It does not become the authority for the record.

Public surveys need extra care

Survey123 can be shared publicly so people without ArcGIS accounts can submit responses. This is useful for community reporting and open questionnaires, but public collection changes the security model.

Esri specifically warns that public surveys containing sensitive information should be configured so anonymous users cannot download, query or modify submitted data.

Survey sharing guidance: https://doc.arcgis.com/en/survey123/analyze/sharesurvey.htm

Public forms should be tested as an anonymous user rather than only as the survey owner.

Check:

• what an anonymous user can submit
• what an anonymous user can view
• whether attachments can be queried
• whether editing is allowed
• whether the feature layer exposes fields not shown in the form
• whether a result map or dashboard exposes raw responses
• whether location should be exact, optional, generalised or absent
• whether free-text answers could expose personal or sensitive information

Do not assume that hiding a question in the form hides the underlying field from every other ArcGIS interface.

Access, sharing and Māori Data Sovereignty

Before collection, decide who should have access to:

• the form
• raw submissions
• exact geometry
• photographs and attachments
• personal information
• reviewer fields
• derived analysis
• dashboards
• public summary layers
• exports

Use separate hosted feature layer views where different audiences need different parts of the dataset.

For example, a taiao project could maintain:

• an internal layer with exact monitoring locations and full field notes
• a partner view with agreed operational fields
• a public layer with generalised locations and summary indicators

Do not publish directly from the unrestricted working layer simply because it is convenient.

Hosted feature layer views: https://doc.arcgis.com/en/arcgis-online/manage-data/create-hosted-views.htm

ArcGIS sharing guidance: https://doc.arcgis.com/en/arcgis-online/share-maps/share-items.htm

Māori Data Sovereignty is broader than an ArcGIS sharing setting. Consider authority, purpose, access, control, storage, retention, reuse and the people represented by the data.

Personal information and consent

A location survey can become personal information very quickly. Names, contact details, voice, photographs, device information and repeated location patterns can identify people even when a form does not contain a field labelled “personal information”.

Collect personal information only where the project has a clear reason to do so. Separate administrative contact details from field observations where possible.

For community or whānau surveys, make the purpose clear and explain how responses will be used. Do not collect demographic information simply because Survey123 provides a convenient question type.

Review before use

Field data should normally move through a review state before it becomes an authoritative working layer or public output.

A simple workflow is:

New submission → field check → reviewer check → correction if needed → accepted working record → approved derivative for sharing

Useful fields include:

• review_status
• review_comment
• checked_by
• checked_date
• follow_up_required
• follow_up_owner

Do not silently “clean” a field observation until it no longer reflects what the collector recorded. Preserve the original value or maintain an edit history where the project needs one.

Reports and operational outputs

Survey123 data can feed several downstream products:

• web maps
• ArcGIS Dashboards
• ArcGIS Experience Builder
• ArcGIS Pro
• QGIS exports
• CSV or spreadsheet analysis
• feature reports
• operational notifications
• webhooks and workflow automation

Feature reports can generate formatted documents from survey records, including maps, images, choices and repeat records.

Report templates: https://doc.arcgis.com/en/survey123/analyze/featurereporttemplates.htm

Webhooks can trigger another process when a response is submitted. Examples include creating a work task, sending a notification, adding a row to another system or calling an organisational workflow.

Webhooks: https://doc.arcgis.com/en/survey123/analyze/webhooks.htm

Treat automation as another data-sharing path. Check what fields and attachments are sent to the receiving service.

Suggested workflow

A practical Survey123 project can follow this sequence:

1. define the kaupapa and intended use
2. identify the people with authority over the collection and use
3. design the data model
4. separate raw observation, interpretation and review fields
5. decide whether location is point, line, polygon, existing geometry or unnecessary
6. decide which questions are required
7. design sensitivity and sharing fields before collection
8. build the smallest usable version of the form
9. test with realistic sample data
10. test offline where field conditions require it
11. test permissions as collector, reviewer, partner and anonymous user where relevant
12. run a small pilot
13. inspect the resulting layer, related tables, attachments and exports
14. revise the form
15. train collectors using the actual devices
16. monitor submissions during the collection period
17. review and approve data before wider use
18. create restricted and shared views for different audiences
19. document ownership, maintenance and handover
20. review the form when the kaupapa, software, team or data sensitivity changes

Field pilot checklist

Before full rollout, complete at least five realistic records and deliberately test awkward cases.

Check:

• no location available
• weak GPS accuracy
• no mobile coverage
• photograph fails or is declined
• required question cannot reasonably be answered
• unusual condition needs “other”
• record is saved but not submitted
• repeat contains several entries
• wrong value needs correction
• collector changes device orientation
• attachment is large
• form is reopened after the app closes
• form is submitted twice accidentally
• reviewer needs to distinguish the two records
• result is exported to CSV
• map displays the geometry expected
• public or partner view hides restricted fields

The best time to discover that a form loses an important identifier is before 600 records have been collected.

Naming and metadata

Use field names that make sense outside Survey123. The form may later be exported, migrated or opened in another GIS.

Prefer names such as:

• site_id
• observation_date
• asset_type
• condition
• follow_up
• gps_accuracy_m
• review_status

Avoid fields whose meaning depends on somebody remembering what Q17 meant.

Keep a short data dictionary describing:

• field name
• label shown to collector
• meaning
• allowed values
• unit
• sensitivity
• whether it is required
• source or calculation
• owner

This is particularly useful when the form survives longer than the project team.

Common design failures

Survey123 projects often become difficult because of ordinary design choices rather than software faults.

Watch for:

• one enormous form trying to support unrelated kaupapa
• hundreds of free-text categories that cannot be analysed consistently
• required fields that encourage guessing
• collecting a new GPS point when a stable site ID already exists
• overwriting previous observations instead of storing repeat visits
• storing AI output without the original evidence
• publishing the working layer directly
• public forms exposing submitted records
• photographs containing information nobody considered sensitive during design
• geometry shown with more apparent precision than the capture method supports
• field names that make sense only inside the original form
• no handover documentation
• no owner for correcting errors after collection finishes

A short survey with a clear purpose will normally produce more useful data than a large form built to capture everything anyone might ask for later.

When Survey123 may not be the best choice

Consider another tool when:

• the workflow is primarily map editing rather than form entry
• the organisation does not use ArcGIS and does not need the ArcGIS ecosystem
• information must remain in local file-based storage for the full project
• the collection must run in an environment where cloud services are not acceptable
• the project requires a function that the chosen Survey123 capture app does not support
• the form is simple and a lower-cost tool such as KoboToolbox meets the need
• the team needs to edit a QGIS project directly in the field
• the project cannot establish satisfactory access, governance or data-handling controls

Compare Field GIS, KoboToolbox and ArcGIS Field Maps.

Useful official resources

• Survey123 website: https://survey123.arcgis.com/
• Product overview: https://www.esri.com/en-us/arcgis/products/arcgis-survey123/overview
• Survey123 documentation: https://doc.arcgis.com/en/survey123/
• What's new: https://doc.arcgis.com/en/survey123/get-started/whatsnewsurvey123.htm
• Functionality matrix: https://doc.arcgis.com/en/survey123/get-started/functionality-matrix.htm
• AI in Survey123: https://doc.arcgis.com/en/survey123/get-started/survey123-ai.htm
• Smart assistants: https://doc.arcgis.com/en/survey123/create/connect/smartassistants.htm
• Repeats: https://doc.arcgis.com/en/survey123/create/main/xlsformrepeats.htm
• Geopoints: https://doc.arcgis.com/en/survey123/create/main/geopoints.htm
• Geotrace and geoshape: https://doc.arcgis.com/en/survey123/create/main/geotracegeoshape.htm
• High-accuracy data collection: https://doc.arcgis.com/en/survey123/create/studio/high-accuracy-prep.htm
• Share surveys: https://doc.arcgis.com/en/survey123/analyze/sharesurvey.htm
• Report templates: https://doc.arcgis.com/en/survey123/analyze/featurereporttemplates.htm
• Webhooks: https://doc.arcgis.com/en/survey123/analyze/webhooks.htm

Related MāoriGIS.nz guidance

Continue with:

• Field GIS
• Marae GIS
• Awa, wetlands, coast and moana
• Marae emergency mapping
• Papakāinga investigation
• AI for Māori GIS
• Before you use AI with Māori information
• Artificial intelligence and GIS
• ArcGIS nonprofit pathway

Last reviewed: 18 September 2026