The Trigger condition Record keyword = UPDATED and UPDATE_ONLY should be used with caution, because the broad scope of these types of criteria may lead to a very frequent execution of the rule. Instead, try to find the key field(s) that will fire the rule properly.

It can be very useful to schedule the execution of an import or report at non-rush office hours. Otherwise, to generate a heavy report during work hours could lead to disrupt the users' other reports and perhaps affect the general performance of the application. They are generated between 2 A.M. and 3 A.M. (first Imports, then Reports) on the given date or interval of execution (e.g., daily, monthly, etc.)

If you need to update data via Imports, create an Update only template with just those columns you need to change, instead of using an existing template that has more than the necessary. Otherwise, the time of execution increases considerably due to the system checking every cell of unnecessary columns.

In a similar way, Reports should also be run according to the specific need. For example, you have a template of the table Order with 10 columns, but for the moment you only need to see the Record name and the "Status" columns; for that, it’s better if you create a new template with only those fields, or you can run it from the Data model editor choosing only those columns, via the Quick report.

The use of scheduled rules may notably affect the performance of the application due to the evaluation periodically executed by the system throughout the criteria of all records of the trigger table. Use it only when necessary. You may ask the IS Tools support team to advise if there are alternatives to succeed in what you want to accomplish.

The Behavior property should be used with caution due to the constant evaluation made on the form. Whenever possible, prefer to use other properties to accomplish what you need instead.

It is always better to design an application creating a Table per key concept in your business model, than trying to put all data into a single Table. On the other hand, having Relation fields connecting Tables, access rights must be checked on every level of the model. That is why it can be appropriate to keep a copy of data in a related Table, in order to speed up this check up. For example, an IQL filter relation1.relation2.field = @somevalue may be significantly slower than filtering on a field in the same table (having a copy of the Parent’s Parent field value into the Child Table via rules). This also applies to reports.

On one hand, Layers allow you to have more components into one form. This can be a good thing if users need more information to perform a task, as they don’t need to go back and forth between forms. But it may be negative if those components are based on Tables not related to that task, loading all together at the same time once the form opens.