Script Frequently Asked Questions

What are the rules of script execution?

Scripts run within a 'transaction' event on creation, update, or deletion of a record. Therefore these scripts and events must be:

• Atomic: Complete in its entirety or have no effect whatsoever
• Consistent: Conform to existing database constraints
• Isolated: Not affect other transactions
• Durable: Written to persistent storage

When do scripts execute?

The following event types support the execution of scripts:

1. Before or after record insert
2. Before or after record update
3. Before or after record delete

A few examples to consider:

• Before insert and before update events can be used to populate data values based on additional logic before save.
• After insert after update events can be used to populate data values from post-save processing, i.e values from 'triggered' field types.

How do I access scripts?

Scripts are associated with tables and table events and accessible from within the table editor.

What limitations are enforced with scripts?

To optimize performance and steadfast security, scripts are executed with the following restrictions:

• Scripts are not executed for large data processing like record import or bulk record update
• Scripts have no access to system-level resources
• Scripts execute on a finite runtime
• Scripts cannot reference 'calculated', 'auto counter', or 'identifier' field types
• Scripts do not have access to network resources - if this functionality is required, use a Microservice

How do I troubleshoot script errors?

Please visit our in-depth knowledge base article for best practices in debugging your scripts.