Overview
This article is a collection of all the various App Script limitations mentioned throughout the App Script articles. Refer to the points listed below for more information regarding of the limitations of App Script functionality.
Click on a link below to jump to that section.
π« Limitations
- General Limitations
- Limitations of App Script Event Types
- Limitations of App Script Functions
- Script Writing - Limitations of Lists
- Script Writing - Limitations of Strings
- Script Writing - Limitations of Variables
- Limitations of Loggers
General Limitations
π« App Scripts CANNOT be triggered to run based on a user opening a View, or a Form. They can only be triggered to run if a record is created, updated, or deleted.
π« App Scripts can only access data that is physically stored in the database β this means that any field that does not store its data in the database cannot be referenced in a script.
The field types that cannot be referenced by App Scripts are: Calculated fields, Auto Counters, and Record ID fields as these fields generate their values on the fly instead of storing their values in the database.
π« App Scripts have limited functionality with Image fields and Document fields. These field types can by referenced by App Scripts to check whether the field contains a file, but the information in the file itself cannot be referenced (e.g. an App Scripts cannot open files attached to a record and access the data within the file).
π« For Mobile device users, App Scripts do not run while the device is offline, and will only run once the device is connected to the Internet.
π« It is important to understand that App Scripts exist outside the context of the App's Table architecture - this means that when something is edited on a Table such as the name of a field, the App Script does not automatically update any references to that field name in the Script.
π« App Scripts CANNOT trigger microservices to run. Microservices are only fired when endpoints for Create, Update and Delete are called (excluding 'bulk' update). They do not fire in response to work done in App Scripts.
Limitations of App Script Event Types
π« Most App Scripts can use "Before Event" triggers, but there are two main instances when App Scripts need to use an "After Event" trigger:
1. When the script references a triggered field - We can see in the order of operations above that the "Before Event" scripts would run prior to any Triggered fields running their calculations, but "After Event" scripts don't run until AFTER Triggered fields have performed their calculations.
2. If the script is creating Child Records upon the creation of a Parent Record. In this case, the Parent record needs to be created and saved to the database first before any Child Records can be created and linked to the Parent Record.
Limitations of App Script Functions
Refer to the Script Writing - Using Functions article for more information and examples.
π« find()
CANNOT search for null values
π« loadRecord()
will result in the error Did not return a unique result: x
if multiple records are found that match the search criteria.
π« The input for the Record Data within the save()
function MUST be a Map
of the fields from the target Table and the values you want placed in those fields. With this in mind, first create a Map
of the record you want to add to the Table, then input the name of the Map as the "Record" in the save()
function.
π«When using the delete()
function, if you delete the record currently in view the UI throws an error message, but the record is still deleted.
Script Writing - Limitations of Lists
Refer to the Script Writing - Working With Lists article for more information and examples.
π« In TrackVia, Checkbox field values are stored as lists. Before manipulating Checkbox field values, you must declare it as a List
. This allows the use of the methods and operations described later on in this article.
Script Writing - Limitations of Strings
Refer to the Script Writing - Working with Strings article for more information and examples.
π«Interpolation - when using String interpolation, double quotes ( " ) MUST be used.
Script Writing - Limitations of Variables
Refer to the Script Writing - Using Variables article for more information and examples.
π« Variables are case sensitive, and so when referencing a Variable in a script, if the Variable name is not identical to the defined Variable name, the script will throw an error. For example, phoneNumber
is not the same as phonenumber
π« When manually declaring a Map
, you DO NOT need to append as Map
as Groovy automatically interprets this syntax as a Map
. However, you DO need to append as Map
when the result you're getting might not already be recognized as a Map
, but you want to ensure that it is treated like one - this mainly applies to record-loading functions like loadRecord()
and find()
.
π« When using def
, if you are declaring a Variable where the data type MUST be clear, such as passing to a method that requires a Map
, you can use def
to declare the variable, but you will need to explicitly define the type by appending as Map
to it.
Limitations of Loggers
π«Loggers can only output strings of text so we must pass a String into the function.
Related Articles:
- App Script Best Practices
- Script Writing - Using Loggers
- Using Variables
- Script Writing - Syntax Rules
Comments
0 comments
Please sign in to leave a comment.