AppScripts operate at the table level on record events and are not associated to any views or forms. They can be configured to trigger on the following record events:
Before Updateevents can be used to set values based on additional logic before saving a record. For instance, using an AppScript to set a value based on the input of another value. The
After Updateevents can be used to set values after the record has saved and Triggered Fields have executed. These events would also be used to create Child Records. Child records require the parent record to exist in order to set the relationship to the parent record.
AppScripts reference applications, tables, fields and relationships. Administrators can change the name of these resources in TrackVia. The system identifiers for these items are unique and immutable and should be used as constants in the AppScript. For example, a field named
Car IDhas a system identifier value of
608. A TrackVia administrator changes the name of the field to
Vehicle ID. The system identifier value will retain its value of
608. When the system identifier is used as a constant in an AppScript, changing the name of a table, field, or relationship will not impact the AppScript functionality. If multiple applications have tables with the same name, the application name can be passed as an optional final parameter to functions in order to identify which table to use. This ensures that the correct table is being acted upon in the AppScript.
To ensure optimum performance and steadfast security, AppScripts have certain restrictions.
- AppScripts are executed in a private container.
- AppScripts do not have access to system resources.
- AppScripts are allocated a finite amount of execution time.
- AppScripts cannot reference
auto counterfield types.
- AppScripts are not executed when performing a
deletewhen more than 1000 records would be effected.
- AppScripts cannot reference Record IDs.
An AppScript is executed within a single
transactionis a change or series of changes that are performed within the scope of a single
commitstatement is the final act of updating data changes to the datastore. Should an operation in an AppScript fail during a
transaction, the changes within the
transactionmay be rolled back to their initial state in order to prevent data corruption. For example, an
After UpdateAppScript loops through its child records and updates a field on each one. If there are 10 child records, and the third child record update fails for any reason, all child records and the parent record will have their values reset to their initial state.