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.
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.
paymentList=List();
for each invoice in PaymentAgainstInvoice[ID == rushPayment]
{
paymentList.add(invoice.ID);
}
//------------------------------------------
//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
[
Added_User=zoho.loginuser
Total_Price=Total_Price
Bill_Status=Bill_Status
];
fetchBill = Bill[ID == billId];
if(patient_Type == "Free")
{
fetchBill.Total_Price=0;
fetchBill.Bill_Status="Closed";
}
//--------------------------------------------
//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")
{
Total_Price=0;
Bill_Status="Closed";
}
billId = insert into Bill
[
Added_User=zoho.loginuser
Total_Price=Total_Price
Bill_Status=Bill_Status
];
Resources
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
Forms
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.
Reports
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.
Pages
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.