Allowed Doctypes Configuration 📋

This section allows you to manage module-wise items in the child table via the Doctype Controller. These settings are reflected in the mobile app under "Allowed Doctypes."

Fields Overview 🛠️

• Doctype Name 🏷️

  • The display name of the module (shown in the mobile app).

• Doctype API Name 🔑

  • The API name of the module, as provided by Zoho's Module API Key.

• Is Enabled ✅ / ❌

  • Toggle to enable or disable the module in the mobile app.

    • If unticked, the module will not appear in the app.

• Edit (Button) ✏️

  • Allows you to edit module configurations by field.

Editing Module Configurations ⚙️

When you click the Edit button (✏️), a new window opens to configure module settings for the mobile app. Below are the key fields you can modify:

1. Create Layout ID 📂

• Specifies which Zoho module layout will be used in the mobile app for creating new records.

• Enter the Layout ID provided by Zoho.

2. Edit Layout ID 📝

• Similar to Create Layout ID, but used when editing existing records in the mobile app.

• You can assign a different layout for editing (e.g., based on mobile-specific validations).

3. Banner Image 🖼️

• Displays a module-specific image in the mobile app.

• Upload an image here, and it will appear as the module’s visual identifier in the app.

4. Query Fields 🔍

• Defines which field data appears in the mobile app.

• Enter the API names of the fields you want to display, separated by commas.

• (Full_Name, Lead_Source, Mobile_User_Email, Phone, Lead_Type, Lead_Stage,)

• Only the fields listed here will be visible in the mobile app.

  
  

  
  

  
  

Module Configuration: List Types & Field Mapping 📱

When editing a module, you can define how its data appears in the mobile app by selecting a List Type and configuring field mappings. Below are the key settings:

5. List Type Selection 🗂️

Choose how records are displayed in the app. Common options include:

• Simple List 🪧

  • Default card-style list (shows 5 fields per record).

• Calendar 📅

  • For appointments, events, or journey plans (displays date/time visually).

• Catalog 🛒

  • E-commerce-style grid view (shows item images + key details).

• Approve-Reject ✅❌

  • For workflows requiring approval actions.

(Screenshot suggestion: Dropdown menu with list type options.)

6. Field Mapping for Simple List 📋

For Simple List, configure these fields to control card content:

Why?

• Zoho’s API keys (Account_Name) fetch data, while Display Names (Partner Name) make it user-friendly.

7. Visual Examples 🖼️

• Simple List → Displays cards with Title, Subtitle, and Trailing fields.

• Calendar → Shows events as dated cards.

• Catalog → Grid of items with images (e.g., product catalog).

  
  

Key Notes 📌

• Use Display Names to simplify technical API keys for end-users.

• Ensure API keys match exactly with Zoho’s field names.

Mobile App Data Filter Configuration Guide

1. Overview

This document explains how to configure default filters for mobile app data display, with two dedicated filter types:

• Search Filters (Search Criteria1) - For user text searches

• User Access Filters (Search Criteria3) - For data visibility control

2. Filter Types & Configuration

A. Search Filters (Search Criteria1)

Purpose: Enable record searching by text input
Location: Always configured in Search Criteria1
Configuration:

Search Criteria1: [API field name for search] # "Name", "Product_Name"
Operator1: [search operator]    # "starts_with", "contains", "equals"
Value1: [dynamic user input]    # Auto-populated from search box

Example:

# When user searches for "Apple"

Search Criteria1: Product_Name
Operator1: contains
Value1: Apple

B. User Access Filters (Search Criteria3)

Purpose: Control which records users can see
Location: Always configured in Search Criteria3
Two Configuration Modes:

1. Personal Records Only:

   Search Criteria3: Mobile_User_Email
   Operator3: equals
   Value3: [auto-detected user email]

2. Personal + Team Records:

   
   

   Search Criteria3: Mobile_User_Email|Reporting_Email_ID
   Operator3: equals
   Value3: [auto-detected user email]
   Post Operator3: OR

   1. Implementation Rules

      Rule	Description
      1	Search Criteria1 must only be used for search functionality
      2	Search Criteria3 must only be used for user access control
      3	Value1 is always dynamic (user search input)
      4	Value3 is always auto-populated (user email)
      5	Use Post Operators only when combining multiple conditions

      4. Example Configurations

      Scenario 1: Basic product search with personal access

      
      

      # Search Configuration
      Search Criteria1: Product_Name
      Operator1: contains
      
      # Access Configuration
      Search Criteria3: Mobile_User_Email
      Operator3: equals

      Scenario 2: Team access with name search

      # Search Configuration
      Search Criteria1: Contact_Name
      Operator1: starts_with
      
      # Access Configuration
      Search Criteria3: Mobile_User_Email|Reporting_Email_ID
      Operator3: equals
      Post Operator3: OR

      ---

      
      

      if wanna give the tab(choice chip filter) that time we need use (Tab Filters) field in this we mention the name

      
      

      
      

      Mobile App Field & Communication Configuration

      1. Communication Settings (Connect Feature)

      Purpose: Enable direct communication (call/email/message) from record details
      Configuration Fields:

      Field	Description	Example Value
      Connect with Phone	API key for phone number field	Phone, Mobile_Number
      Connect with Email	API key for email field	Email, Contact_Email

      
      

      Behavior:

      • When populated fields exist in a record, communication icons appear (call/email/WhatsApp)

      • Icons only show if the corresponding field has valid data

        Connect with Phone: Mobile_Number
        Connect with Email: Work_Email

        
        

   2. Form Field Management

   A. Create Fields

   Purpose: Control which fields appear in mobile create forms
   Configuration:

   • List API keys of fields to show (comma-separated)

   • Include section headers with [Section Name] prefix

   • (Example:) (Lead Information,Lead_Type,Lead_Sub_Type,Referred_Partner)

   
   

   ---

   B.Details Fields

   Primary Fields
   Account_Name, Phone, Email
   Additional Info
   Industry, Annual_Revenue, Website

   C: Edit Fields

   Primary Fields
   Account_Name, Phone, Email
   Additional Info
   Industry, Annual_Revenue, Website

   ---

   Tab Filter Configuration for List Views

   1. Overview

   Enhance user experience by implementing tab-based filtering (chip filters) for record lists. This allows quick filtering of records by status or other key categories.

   2. Configuration Components

   Required Fields

   Field	Purpose	Example Value
   Tab Filters	Display names for tabs	Assigned, Pending, Closed
   Search Criteria1	Corresponding API field name	Status
   Operator1	Filter comparison operator	equals, starts_with

   
   

   UI Behavior

   1. Visual Elements

      • Tabs appear as horizontal chips above lists

      • Active tab highlighted

      • Badge counts show record quantities

   2. Interaction

      • Single-click applies filter

      • Defaults to first tab

      • Instant reload without page refresh

   
   

   Best Practices

   1. Tab Design

      • Limit to 5-7 tabs for mobile

      • Order by workflow sequence

      • Use clear, short labels

   
   

   ---

   Mobile App Special Feature Configuration

   1. Appointment Feature

   Purpose: Enable check-in/check-out functionality for field visits or meetings

   Activation

   • Toggle "Is Appointment" field to enable

   • Requires API field mapping from Zoho CRM

   Required Field Mappings

   (All fields require exact Zoho CRM API keys)

   Field Group	API Fields	Description
   Check-In	Checkin_Lat, Checkin_Long	GPS coordinates
   	Checkin_Time	Automatic timestamp
   	Checkin_State, Checkin_City, Checkin_Area	Location details
   Check-Out	Checkout_Lat, Checkout_Long	GPS coordinates
   	Checkout_Time	Automatic timestamp
   	Checkout_State, Checkout_City, Checkout_Area	Location details
   Result	Outcome	Visit summary/notes

   
   

   Example Configuration:

   Is Appointment: [Enabled]
   Checkin_Lat: Location_Latitude__c
   Checkin_Long: Location_Longitude__c
   Checkin_Time: Start_Time__c
   Outcome: Meeting_Summary__c

   2. Expense Feature

   Purpose: Enable expense tracking and reimbursement requests

   Activation

   • Toggle "IsExpense" field to enable

   • Requires expense category field mappings

   Required Field Mappings

   Field	Type	Example API Keys	Description
   Super Type	Dropdown	Expense_Type	Public/Private travel
   Sub Type	Dropdown	Vehicle_Type	Bike/Car/Flight
   Journey Date	Date	Travel_Date	Expense date
   Distance Travelled	Number	Distance_Km	In kilometers/miles
   Claim Type	Dropdown	Expense_Category	Travel/Food/Medical
   Description	Text	Expense_Notes	Purpose/details
   Amount	Currency	Expense_Amount	Claim value

   
   

   Example Configuration:

   IsExpense: [Enabled]
   Super Type: Travel_Mode__c
   Sub Type: Transport_Type__c
   Claim Type: Expense_Category__c
   Amount: Total_Claim__c

   Dropdown Value Reference

   • Super Type: Public, Private

   • Sub Type: Bike, Car, Flight, Taxi

   • Claim Type: Travel, Food, Medical, Lodging

     
     

Field Visibility & Form Validations

Overview

This document outlines the field visibility rules and form validations applied to the Create & Edit forms. These rules ensure that only relevant fields are displayed and validate user inputs before saving.

Field Visibility Validations

Use Case

When selecting a Payment Method, specific fields should be displayed based on the selected option:

• If UPI is selected, the UPI_Id field should be visible and required.

• If Cheque is selected, the Cheque_no and Cheque_Information fields should be visible and required.

• If Cash, NEFT/RTGS, or UPI is selected, the Cash_UPI_NEFT_Information field should be visible and required.

Implementation

The following structure defines the field visibility rules in a Dart evaluation script (dart_eval field inside the Allowed Doctypes child table):

Field Visibility Configuration

Map<String, dynamic> FieldValidations() {
  return {
    "conditions": [
      {
        "depends_on": "Payment_Method",
        "field_type": "picklist",
        "dependent_fields": [
          {
            "field_name": "UPI_Id",
            "req_options": "UPI",
            "visible_options": "UPI",
            "required": true,
            "visible": true,
            "read_only": true
          },
          {
            "field_name": "Cheque_no",
            "req_options": "CHEQUE",
            "visible_options": "CHEQUE",
            "required": true,
            "visible": true,
            "read_only": true
          },
          {
            "field_name": "Cheque_Information",
            "req_options": "CHEQUE",
            "visible_options": "CHEQUE",
            "required": true,
            "visible": true,
            "read_only": true
          },
          {
            "field_name": "Cash_UPI_NEFT_Information",
            "req_options": "CASH,NEFT/RTGS,UPI",
            "visible_options": "CASH,NEFT/RTGS,UPI",
            "required": true,
            "visible": true,
            "read_only": true
          }
        ]
      }
    ]
  };
}

Explanation of Parameters

Behavior Example

Form Validations on Save Button

Use Case

To prevent incorrect data submission, the form enforces validation rules before saving:

• The Amount Received should not be greater than Balance Due.

• The Payment Method cannot be set to an invalid static value ("H").

Implementation

The following structure defines the form validation rules applied to the Create & Edit forms(dart_eval field inside the Allowed Doctypes child table):

Form Validation Configuration

Map<String, dynamic> FormValidations() {
  return {
    "edit_validations": [
      {
        "key": "Form-Amount_Received",
        "operator": ">",
        "value": "Record-Balance_Due1",
        "error": "Amount {Form-Amount_Received} Can't be Greater than Balance Due {Record-Balance_Due1}"
      },
      {
        "key": "Form-Payment_Method",
        "operator": "==",
        "value": "Static-H",
        "error": "Payment Method Can't be H"
      }
    ],
    "create_validations": [
      {
        "key": "Form-Payment_Method",
        "operator": "==",
        "value": "Static-H",
        "error": "Payment Method Can't be H"
      }
    ]
  };
}

Explanation of Parameters

Validation Behavior Example

Best Practices

• Ensure that validation rules are applied correctly for both Create and Edit operations.

• Always provide meaningful error messages to help users correct their input.

• Keep the structure flexible by adding new validation rules as needed.

• You will found this code this dynamic_form.dart & edit_dynamic_form.dart

• If You want to Static value then Define as "Static-{Your Value}"

• If You want from Record value then Define as "Record-{Your Value}"

• If You want from Form value then Define as "Form-{Your Value}"

  
  

Here's your Shorebird commands with emojis added for better visual appeal and clarity:

🚀 Shorebird Release Command
shorebird release android --flutter-version 3.22.3 --artifact=apk

🩹 Shorebird Patch Command
shorebird patch --platforms=android --release-version=1.0.60+60