> ## Documentation Index
> Fetch the complete documentation index at: https://support.fieldko.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Record Types and Validation Rules

> Learn how FieldKo uses record types to pick layouts, and how to write validation rules that don't block reps' offline work at sync.

Record types and validation rules behave differently in FieldKo than in a desktop-only org. FieldKo switches visit and task record types automatically as work progresses, and validation rules run when a rep syncs, not when they tap **Save** offline. This page explains both, and how to write rules that protect your data without blocking reps in the field.

## User Permissions Needed

| To do this | You need |
| - | - |
| Create record types and validation rules | Customize Application |
| Create custom permissions | Manage Custom Permissions |
| Read sync errors | FieldKo Native Permission Set |

## Record Types That FieldKo Installs

| Object | Record Types | How They're Used |
| - | - | - |
| Visit | **Not Started**, **In Progress**, **Completed**, **Cancelled** | FieldKo sets the record type to match the visit's status. The app switches it at check-in and check-out, and **Cancel Visit** sets **Cancelled**. |
| Task | **Not Started**, **In Progress**, **Completed** | FieldKo sets the record type to match the task's status. |
| FieldKo Order | **Sales Order**, **Return Order** | The type of order |
| Account | **Store**, **Brand**, **Banner** | Optional. **Store** is the default account record type for visit planning. |
| Sync Detail | **Sync State**, **Error Information**, **Transaction State**, **App State** | Kinds of sync log. See [Sync Details](/admin/support-diagnostics#sync-details). |

Because visits and tasks change record type as they progress, each status can have its own page layout. Use this to show reps the right fields at the right time: planning fields on Not Started, task and photo fields on In Progress, and a read-only summary on Completed.

<Warning>
  Don't rename, deactivate, or delete the Visit and Task record types, and don't remove them from reps' profiles or permission sets. FieldKo and the app find them by name to switch them at check-in and check-out. If they're missing or renamed, visits and tasks can keep the wrong record type and layout.
</Warning>

You can add your own record types to objects such as Account, Contact, or your own objects. Don't add your own Visit or Task record types to tell kinds of visits apart, because FieldKo replaces the record type when the status changes. Use [visit types](/admin/call-cycles-and-visits#visit-types) or a custom field instead.

If you add account record types, select the ones reps plan visits for in **Account Record Types for Visit Planning** on the **FieldKo Configuration** tab, under **Basic**.

## How the App Picks a Layout

For each record, the app shows the page layout assigned to the rep's profile for the record's record type. Records with no record type use the object's master layout assignment. A **FieldKo Layout Override** record can replace the layout for some profiles or record types. See [Page Layouts](/admin/configuration-reference#page-layouts).

After you change record types or layout assignments, rerun the Metadata Collector and ask reps to run **Reset Sync**. See [Add Fields and Picklists to the Mobile App](/platform/customize/fields-in-the-app).

## How Validation Rules Affect Reps

Reps work offline, so Salesforce doesn't see a rep's changes until the app syncs. Validation rules, required fields, and triggers all run then. When a rule fails:

* The record doesn't save in Salesforce. The rest of the sync continues, and the sync finishes as **Partial Sync**.
* The rep sees the record under **Sync History** > **ISSUES**, with your rule's error message.
* An **Error Information** sync detail record shows `FIELD_CUSTOM_VALIDATION_EXCEPTION` and the message. See [Records Fail to Upload](/admin/support-diagnostics#records-fail-to-upload).

A rule that's harmless on desktop, where the user fixes the record on the spot, can leave a rep with a visit that won't upload long after they've left the store. For what reps can do, see [Fix Sync Errors](/troubleshooting/sync-errors).

FieldKo's own active rules check things the app already enforces, such as a visit's planned end being after its planned start ("End Date should be greater than Start Date") and call cycle dates.

## Write Mobile-Friendly Validation Rules

Use these patterns for rules on objects that reps change in the app:

* **Only require fields that are on the rep's layout.** If a rule needs a field the rep can't see or edit in the app, the rep can't fix the record. Add the field to the layout for every record type the rule applies to, and mark it **Required** on the layout so the app checks it before the rep saves.
* **Exempt mobile users with a custom permission.** Create a custom permission, such as `Bypass Desktop Validation`, add it to a permission set for reps, and add `NOT($Permission.Bypass_Desktop_Validation)` to the rule's formula. Enforce the rule for desktop users only. See [Custom Permissions](https://help.salesforce.com/s/articleView?id=sf.custom_perms_overview.htm\&type=5) in Salesforce Help.
* **Don't block status changes.** Avoid rules that stop a visit from moving to **In Progress**, **Completed**, or **Cancelled**. If a check-out fails at sync, the visit stays open in Salesforce and reports show it as missed.
* **Fix data later instead of rejecting it.** For data quality checks, consider a flow or report that flags the record for a manager instead of a rule that rejects the rep's work. See [Keep Data Clean](/platform/data/data-quality).
* **Test with a rep user.** In a sandbox, make the change in the app offline as a test rep, sync, and check **Sync Details** for errors before you activate the rule in production.

The Visit, Task, and Task Survey objects also have a **FromDevice** checkbox, which the app selects on some of the saves it makes, such as check-in and check-out. FieldKo's own task survey rule uses it. The app doesn't select it on every save, so use a custom permission when you need a reliable exemption.

For validation rule syntax, see [Validation Rules](https://help.salesforce.com/s/articleView?id=sf.fields_about_field_validation.htm\&type=5) in Salesforce Help.

## See Also

* [Fix Sync Errors](/troubleshooting/sync-errors)
* [Diagnose Rep Issues](/admin/support-diagnostics#records-fail-to-upload)
* [Add Fields and Picklists to the Mobile App](/platform/customize/fields-in-the-app)
* [Extend FieldKo Safely](/platform/customize/extend-safely)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.