Events

App Scripts 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 Insert
• After Insert
• Before Update
• After Update
• Before Delete
• After Delete

The Before Insert and Before Update events can be used to set values based on additional logic before saving a record. For instance, using an App Script to set a value based on the input of another value. The After Insert and After Update events 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.

Referencing Data (Best Practice) 

App Scripts 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 App Script. For example, a field named Car ID has 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 App Script, changing the name of a table, field, or relationship will not impact the App Script 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 App Script.

Restrictions

To ensure optimum performance and steadfast security, App Scripts have certain restrictions.

• App Scripts are executed in a private container.
• App Scripts do not have access to system resources.
• App Scripts are allocated a finite amount of execution time.
• App Scripts cannot reference calculated or auto counter field types.
• App Scripts are not executed when performing a batch update or delete when more than 1000 records would be effected.
• App Scripts cannot reference Record IDs.
  
  

Transactionality

An App Script is executed within a single transaction. A transaction is a change or series of changes that are performed within the scope of a single commit statement. A commit statement is the final act of updating data changes to the datastore. Should an operation in an App Script fail during a transaction, the changes within the transaction may be rolled back to their initial state in order to prevent data corruption. For example, an After Update App Script 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.