How to Build a Field Visit App with OTP and GPS Verification in Clappia

Self-reported field visit data has a well-known reliability problem. Without verification, a visit log is a record of what a field representative says happened, not necessarily what did. For organisations managing large field teams across dispersed territories, the gap between reported and actual visits can distort performance metrics, misdirect management attention, and erode the data quality that decisions are based on.

Building verification into the visit form itself, rather than treating it as an audit activity that happens after the fact, is a more effective approach. When a form requires an OTP that can only be obtained at the store and a GPS location that must fall within a defined radius of the registered outlet before submission is allowed, the visit record carries its own proof of presence. No separate audit step is needed because the evidence is embedded in the data.

This guide walks through how to build that verified field visit system in Clappia from scratch: a master directory that stores retailer data and GPS coordinates, a visit logging app with two-factor presence verification, outcome tracking with conditional fields, and an on-save workflow that assigns owners, schedules follow-up reminders, and pushes data to external systems.

System Overview: Three Apps, One Workflow

The complete field visit system uses three Clappia apps working in sequence. Building them in order matters because the visit app depends on the master directory being populated first.

Step 1: Build the Retailer Master Directory

Log in to your Clappia workspace, click '+ New App' from the home screen, and select a blank template. Name it 'Retailer Master Directory'. This app has no workflows. Its only function is to store retailer data cleanly so the visit form can pull from it reliably.

Add the following fields in a single section, all as Single Line Text blocks unless noted:

• Retailer ID: A unique identifier per store. This is what the visit form uses to reference the retailer in downstream workflows and the daily tracking linkage.
• Retailer Name: The store name, used as a search key and displayed in notifications.
• Retailer Contact Number: The primary phone number, used as the second search key in the visit form.
• GPS Coordinates: Use a GPS Location block. This stores the store's registered physical location and is what the visit form compares the rep's live location against. Set it to default to the current location when the record is created or edited, so whoever is entering the record can capture it accurately on-site.
• Postal Code: The store's postal code (PIN code, postcode, or zip code depending on your region). Used as an alternative search path in the visit form and as a filter for the embedded map view.
• Field Representative Name, Email, and Contact: The rep assigned to this retailer.
• Territory Manager Name, Email, and Contact: The territory-level manager responsible for this retailer.
• Zone, Region, Territory: Three-level geographic classification. Mark all three as required. These are used by the visit workflow to look up the correct regional and zonal manager contacts for owner assignment.

Add a Validation block that fires on every new submission attempt and displays the message: 'New retailer records cannot be created here. Please contact your data administrator.' This prevents field reps from adding retailers directly through the visit app's lookup and keeps master data under centralised control. Editing existing records remains allowed.

Once the app is built, import or manually enter your complete retailer list before any field team starts logging visits. The visit form's auto-fill and both verification checks depend on this data being present and accurate.

Step 2: Build the Field Visit Logger Form

Create a second new app named 'Field Visit Logger'. This is the form your field representatives open at each store. The design goal is speed with integrity: the rep makes two selections to find the store, completes two verification steps, records the visit outcome, and submits. Every other field fills itself automatically.

Retailer Lookup: Two Search Paths

Add two Get Data from Other Apps blocks, pointed at the Retailer Master Directory. These blocks let the form pull information from another app in your Clappia workspace based on a search value the user enters.

Search path 1 (by name or contact number): Configure this block to search the master directory by retailer name or contact number. When the rep selects a match, the following fields auto-populate as read-only: Retailer Name, Retailer ID, Retailer Contact Number, GPS Coordinates (store location), Field Representative contact details, Territory Manager contact details, Zone, Region, Territory, and Postal Code.

Search path 2 (by postal code): A second lookup block that filters the master directory by postal code. This is useful when a rep is working an unfamiliar area and wants to see all registered stores in a given postcode zone. When this path is used and a postal code is selected, an embedded analytics view filtered to that postal code becomes visible in the form, showing registered retailer locations on a map.

Both paths populate the same downstream fields. The rep uses whichever is faster. All auto-filled fields must be read-only to prevent accidental overwriting of master data through the visit form.

Email Cleanup Formulas

Contact email values pulled from the master directory sometimes carry stray whitespace or formatting characters introduced during data entry. Add two Formula blocks to produce clean email strings for use in workflow owner assignment:

TRIM({Field Representative Email})

TRIM({Territory Manager Email})

Fields used: Field Representative Email, Territory Manager Email (both pulled from the master directory).

What the formulas do: Strip leading and trailing whitespace from the email strings.

What the user sees: These are hidden formula fields, not visible to the rep. The workflow uses their output values when assigning owners, ensuring email addresses are valid and match-ready.

OTP Verification

OTP verification is the first of the two presence checks. It requires the rep to obtain and enter a code that can only be retrieved on-site, confirming they are physically at the store rather than logging the visit remotely.

• Authenticator Code field: Add a Number block labelled 'Enter Authenticator Code'. Set a display condition so this field only appears when the form is in its initial, pre-submission state. The rep types the OTP they obtain at the store here.
• Verify OTP button: Add a Button block labelled 'Verify OTP'. Configure it to call your external OTP validation API via a REST API action. Map the entered code as the request payload. The API response (a success or failure indicator) is captured in a hidden text field.
• Validation messages: Add two Validation blocks that read the hidden response field. One fires when the response indicates success and shows 'Valid OTP'. The other fires when the response indicates failure and shows 'Invalid OTP', blocking submission until the check passes.

The OTP step creates a verification record embedded in every submission. Because the validation prevents saving with a failed OTP, there is no way to submit a visit without a passing verification response stored in the record.

GPS Proximity Check

Add a GPS Location block labelled Your Current Location. Configure it to default to the device's live coordinates. This block should only become visible after the rep has selected a retailer (use a display condition tied to the Retailer ID field being non-empty). Until a retailer is selected, there is no store location to compare against, so showing the GPS capture field early adds no value.

Add a Validation block that calculates the distance between the rep's current coordinates and the store's GPS coordinates from the master directory. Set the boundary to 200 metres. If the distance exceeds this threshold, the validation fires with a message such as: 'Your current location appears to be more than 200 metres from this store. Please confirm you are at the correct location before submitting.'

The 200-metre threshold is intentionally configurable. Urban retail environments with dense store clustering may warrant a tighter boundary like 100 metres. Rural areas with variable GPS signal accuracy may need 300 to 500 metres. Set it based on what is operationally realistic for your territory layout.

For support and admin users who need to access the form without being physically present, add a display condition to the GPS validation that exempts users with a specific support role flag. Add a Distance (metres) diagnostic field visible only to support users that shows the raw haversine distance between the two coordinates. This gives your support team the information needed to investigate GPS-related submission issues without exposing it to field reps in the normal flow.

Visit Outcome Fields

After verification is complete, the rep records the outcome of the visit. Add two Single Selector blocks, both required:

• Shop Open: Yes / No.
• Order Placed: Yes / No.

When Order Placed is set to No, two additional fields appear via display condition. Add a Long Text block labelled 'Additional Products Required' and a Date block labelled 'Next Visit Date'. Mark Next Visit Date as required when it is visible. The rep cannot submit a no-order visit without committing to a specific follow-up date, which the workflow uses to schedule an automated reminder.

Submission Settings

In the app's submission settings, make the following configurations:

• Button label: Set to 'Record Visit' so the submission action is clearly named and distinct from a generic save or submit.
• Authentication required: Enable this so only logged-in users can submit. This prevents anonymous submissions and ties every visit record to a specific Clappia user account.
• Drafts disabled: Disable draft saving. A visit form should either be submitted completely or not at all. Partial drafts create ambiguity about whether a visit actually took place.
• View submissions disabled: Field reps should not be able to view other reps' visit records through the form interface. Viewing is managed through the submissions list with appropriate access controls.
• Post-submission message: Configure a confirmation message that displays the submission ID after a successful visit log. This gives the rep a reference number they can quote if a submission needs to be looked up later.

Step 3: Configure the On-Save Workflow

Open the Field Visit Logger app, go to Design App and then Workflows, and find the New Submission Flow. This workflow fires every time a new visit is saved. Add the following actions:

Owner Assignment

Add the territory manager's email (from the cleaned formula field) as an owner of the submission. This gives the territory manager visibility into the visit record immediately after it is saved, without needing to manually share or forward anything.

For regional and zonal management visibility, add a Get Data from Other Apps action in the workflow that queries a contacts mapping app using the Zone and Region values from the visit form. This lookup returns the correct regional and zonal manager emails for that territory, which are then added as additional owners. If you do not have a separate contacts mapping app, you can use static email addresses per zone and region directly in the workflow for a simpler initial setup, adding the dynamic lookup later.

Follow-Up Reminder for No-Order Visits

Add a Condition block that checks whether Order Placed equals 'No'. Under the matching branch, add a Wait node configured to wait until the Next Visit Date at approximately 9 AM. After the wait, add a Mobile Notification action addressed to the submitter:

Reminder: Follow up with {Retailer Name} today. Products discussed: {Additional Products Required}

The wait is anchored to the date value entered by the rep at the time of the visit. The reminder fires on that specific morning regardless of when the submission was created or synced.

Daily Tracking Linkage

Add an Edit Submission action that finds today's live tracking record for the same user (queried by submitter email and today's date) and updates it with the Retailer ID of the current visit. This links each visit to the day's route record, so the tracking timeline shows which stores were visited and in what sequence. If no tracking record exists for the day (for example, if the rep forgot to start live tracking), the edit action fails silently without affecting the visit submission.

External Data Push

Add a REST API action that sends the visit payload to your external system. Map the relevant fields: Submission ID, submitter email, Retailer ID, Retailer Name, Order Placed, Next Visit Date, Additional Products Required, and the visit timestamp. Configure error handling so a failed external push does not block the submission from saving in Clappia. The visit record is the source of truth; the external push is a downstream integration that can be retried via the on-review workflow if the initial send fails.

Step 4: Build the Daily Live GPS Tracking App (Brief)

The daily tracking app is a companion to the visit logger, not a standalone product. Its role is to record the rep's full day route and provide a container that each individual visit can be linked back to.

Create a new app named 'Daily Live GPS Tracking'. Add a Date block (defaulting to today), a Single Selector block for role (Field Representative or Territory Manager), and a Live Tracking block that starts GPS route recording when activated. Add a Validation block that prevents more than one tracking session per user per day by querying existing submissions filtered by submitter email and today's date.

The travel summary fields (starting and ending GPS location, start and end time, total distance) are shown only after the record is saved, since they are populated as the tracking session progresses and concludes. The on-save workflow assigns the correct managers as owners based on the rep's role, using a lookup similar to the visit app's owner assignment.

Step 5: Access, Permissions, and Mobile Use

Both the visit logger and the tracking app are designed for mobile-first use. Configure access in Clappia under 'Manage Users' for each app:

• Field representatives: Submit access only on the visit logger and tracking app. They cannot view other reps' records, edit past submissions, or access the master directory.
• Territory managers: View access to submissions in their territory, granted automatically through the owner assignment workflow rather than through a blanket permission.
• Regional and zonal managers: View access to their zone's submissions, also granted through the workflow's dynamic owner assignment.
• Data administrators: Full access to the Retailer Master Directory for creating and editing retailer records and GPS coordinates.

Offline mode in the Clappia mobile app is important for field use. Reps in areas with poor connectivity can complete the OTP verification, fill in all visit fields, and submit. The form saves locally and syncs when the device reconnects. The on-save workflow fires at sync time, including the follow-up reminder scheduling and the external data push. The GPS proximity check uses the device's locally cached location data, so it functions correctly offline as long as the device GPS is active.

Quick Reference: Field Visit Logger Components

Conclusion

A field visit app with OTP and GPS verification is meaningfully different from a standard visit logging form. The verification steps transform the record from a self-reported entry into an evidenced one, which changes what the data can be used for: performance reporting that managers can trust, compliance audits that do not require separate evidence collection, and follow-up workflows that trigger on verified events rather than unverified ones.

The build described in this guide is modular. The master directory and visit form are the core; the daily tracking linkage and external data push are extensions that can be added once the core is working and tested. If you are deploying this for the first time, build the master directory, populate a subset of retailers, configure the visit form with the two verification checks, and run end-to-end tests with real devices before rolling out to the full field team. The GPS boundary and OTP flow in particular need to be tested in actual field conditions, not just from a desk, because network latency and device GPS accuracy behave differently in the environments your reps work in.