Choose the right plan

Before we start creating an application in Zoho Creator, it's important to understand what the Creator platform can offer and what usage limits are applicable for each plan.

As a rule of thumb, it's ideal to have at least 5 - 10 percent more limits than required. This will ensure that your application can scale in case there is a spike in user activity.

Choose what type of users will be using the app. For customers to access your application, ensure you choose a plan that offers the customer portal feature.

Security Best Practices

Users & Permissions

Only the required users should be added to the application, and only the necessary modules should be shared.

Users or developers who no longer require access to the application should be removed.

When more than one user is building the app, add the required users as developers instead of sharing the admin credentials.

Access to APIs, as well as PII (Personally Identifiable Information) and ePHI (Electronic Protected Health Information) data can be given to the necessary permission sets alone.

Export, Delete, View All, and Bulk Edit permissions must be limited.

Permission sets that are not required for Users and Customers can be deleted.

Forms & Reports

Fields that collect or contain PII and ePHI data should be encrypted.

Sensitive information can be masked in reports wherever applicable.

Filters and criteria can be added to reports to ensure only the required information is displayed to users.

Any sensitive information that is stored can be deleted when it is no longer required.

Confirmation messages can be associated with Custom Action buttons.

It is not advisable to collect or store sensitive information like SSN or Passwords. If collected, the purpose should be stated in the form.

It is best to avoid storing API credentials in the application.

Help text or tooltips can be associated with fields to elaborate on the reason for collecting the data.

Note fields can be added to forms to specify the purpose of data collection.

It is advisable to deactivate published forms when public access is no longer required.

Decision box can be used to obtain consent for data collection.

OAuth-based authentication should be used wherever possible when invoking APIs.

When collecting details on user location and IP address, it is advisable to inform them of the this and obtain their consent. IP address can also be encrypted.

Actions in reports like Add, Delete, and Duplicate must be reviewed, and can be removed if not required.

The history of changes made to records can also be tracked using the Audit Trail feature.

Workflows & Scripting

Input validations should be done for fields wherever possible.

Any hyperlinks used in the application should be verified.

Content in SMS, Email, and Push Notification tasks should be reviewed.

Business logic like Functions and Schedule Workflows can be executed inside the workflow builder itself before being incorporated in the main flow.


HTML and JavaScript codes should be reviewed.

Use comments wherever possible.

For pages that work based on parameters, make sure to include null checks to prevent the page from displaying errors or irrelevant data.

Avoid duplicating CSS styles.


Zoho Creator - GDPR Readiness

Zoho Creator - Help & Resources

Application Best Practices

Generic Practices

Define the application structure, identify the data model - fields, the relationships, encryption of fields, and take in to account the pain points of the current process before beginning to build the application.

Document the application structure. This will make it easier to make changes later.

Assign meaningful names for all components - Forms, Fields, Reports, Workflows, Pages, Variables, Functions, and Permission Sets.

Use lookup fields to create relationships between the forms to avoid redundant data across forms.

Set properties like Mandatory and No Duplicate values to fields to maintain data integrity.

Delete components that are not required from the application.

Specify delete behavior of records - what will happen to any related records when a particular record is deleted. For example, if an employee is deleted, what will happen to the tasks assigned to them?

Make and test changes to the application in a sandbox environment before publishing.

Workflow Execution Throttle - Only 100 Deluge Workflows can be executed per IP address per minute.

Use the scheduled app backup feature to create periodic backups.

Improving Performance:

  • Make use of the predefined deluge functions: equalsIgnoreCase, equals for comparison rather than "==".
  • Archiving large amounts of data

Deluge Best Practices

Generic Practices

Debugging statements like "info" can be used wherever applicable to weed out errors.

Avoid heavy nesting of scripts and optimize loops.

Use the aggregate record task effectively. Fetch all records only when needed.

Use the built-in functions wherever possible—these are optimized for performance.

Try-Catch statements can be used to handle exceptions in the code.

Variables can be given meaningful names.

Make use of system variables like zoho.appUri and zoho.appName so that the application link name or the owner name changes do not affect your functionality. This is especially useful for Deluge script used inside HTML pages for embedding components.

Functions can be used to create reusable code blocks out of frequently used or duplicated code.

Unwanted and commented code can be removed to keep the code base clean for easier maintenance.

Scripts can be indented and comments can be added to them to provide a short overview of the logic and purpose.

Keep the code modular.

Syntax Assist can be used to help configure tasks.

Versioning is also available to track the various versions and code changes.

When making use of the invokeURL Deluge task to make API calls, the response is not stored or processed at Zoho Creator end, which makes Deluge safe from any vulnerabilities.

Any errors in Deluge Scripting will only affect the application logic, and will not cause any vulnerabilities.

Syntax errors that arise in Deluge will be displayed when a user tries to save the script. The code will not be saved or executed until the error is rectified.

Logical errors that occur due to poor programming practices and mistakes must be traced and fixed.

Any deluge code written must be optimized to ensure the Deluge Statement Limits are not reached. These have been set to prevent accidental misuse of resources.

Scripts to be avoided

The following are a few scripts that can be avoided and alternatives for them.

Example 1:

Instead of checking the count from the fetch statement, you can directly use the fetch collection inside the loop.

fetchInvoices = Invoice[Client == input.Client && Location.equalsIgnoreCase("Chennai") && Bill_Payment_Status == "Not Paid"];
if(fetchInvoices.count() > 0){
for each invoice in fetchInvoices
//Instead use the below script
for each invoice in Invoice[Client == input.Client && Location.equalsIgnoreCase("Chennai") && Bill_Payment_Status == "Not Paid"]{

Example 2:

Make use of built in functions to avoid looping.

for each invoice in PaymentAgainstInvoice[ID == rushPayment]
//Instead use the below script
paymentList = PaymentAgainstInvoice[ID == rushPayment].ID.getAll();

Example 3:

Use count function to avoid looping.

fethcInvoice = Invoice[ID == input.invoiceId];
for each  lineitmcount in fethcfrominv.Line_Items
contlines = contlines + 1;
//instead use the below script
count=fethcInvoice = Invoice[ID == input.invoiceId].count(ID);

Example 4:

billId = insert into Bill
fetchBill = Bill[ID == billId];
if(patient_Type == "Free")
//Instead of using the above code we can perform the check before inserting the data to the Bill form. This will avoid the unnecssary update operation 
if(patient_Type == "Free")
billId = insert into Bill


Deluge - Things to Keep in Mind

Mobile App Best Practices

The actions and the events during which the actions are triggered like tap of a record, swipe left, and swipe right can be determined and changed.

Columns in the quick view and detail view can be set according to the app context.

Custom logo can be uploaded to the applications.

Applications can be rebranded and published separately for users and customers.

Usability & User Experience Best Practices


Multi-column layouts (1, 2, 3) can be used to break a form into smaller parts.

Sections can be used to logically group fields based on context.

Field size and the position of field labels can be manipulated.

Tooltips and help texts can be used to help the users understand the inputs required for a field.

Success messages can be added to acknowledge submissions.

Notifications: Email, SMS, and Push Notifications can also be configured to be sent to users on relevant actions.

Appropriate messages and alerts can be displayed to provide visual assistance.


Contextual messages can be used to personalize the messages that appear in reports with appropriate content.

Only the most important and relevant columns should be added to the Quick View of a report.

Other information can be added to the Detail View and can be grouped logically using blocks.

Freeze columns of a report to maintain the context of the record when scrolling through a report.

Conditional Formatting can be used to highlight specific records based on certain criteria.

Frequent actions can be simplified using custom action buttons and placed as a header action.

Custom Action buttons can be configured to have confirmation messages before being executed.

Custom Layouts and Record Templates can be used to further customize the appearance of records based on context.


A dashboard is intended to get a comprehensive overview of the processes in the application. Hence, it is not advisable to overload it with multiple components.

Adding more than 10-15 components may increase the cognitive load for users.

Multiple pages can be created based on context.

Application Navigation

Themes can be used to change application navigation: top, left, grid navigation.

If you have any further queries, please feel free to reach out to us

Contact us