Scripts wouldn't be very useful unless they had access to the NEON data models and variables, such as Data Lists, Sheets, Survey answers, Competition entries etc.

This page describes the various variables that are available within the scripts.

Member related Entity variables

If the Member is not known, these variables return null, otherwise the record for the passed-in Member will be looked up in the database.

_members, AllMembers, _me

Returns a reference to the _members data.

For example _me.email returns the Member's email address.

List-name or list-id

Looks up the List record for the Member.

TAG Lists

Has no attributes. Simply returns a boolean based on if the Member exists in the Tag List or not

For example ${VipMember ? "Welcome" : "Hi"}

SUBSCRIPTION Lists

Has no attributes. Simply returns the subscription state.

For example ${Newsletter == 'SUBSCRIBED' ? "Thanks for subscribing" : "Sorry to see you go"}

COUNTER Lists

Has no attributes. Simply returns the Member's counter value.

For example "You have already entered the survey " + SurveyCounter + " times"

DATA Lists

Returns a Map with all field values.

For example ${profile.lastName}

SQL Lists

Returns a Map with all field values, the same way as Data Lists.

Note that referencing SQL Lists within scripts may have a dramatic impact on performance, depending on the cost of the SQL Query.

Target Lists

Same as TAG Lists, returns a boolean value, which is true if the Member exists in the Target.

Note that caution should be used with basing scripts on Target Lists since they may be recalculated at any time, which could affect the scripting Logic.

The script throws an error if the Target has become invalid

Member-Sheet-name or Member-Sheet-id.

Requires the key to be passed in, in order to lookup the record. The MemberId does not form part of the key. If the Sheet uses composite keys, all values have to be passed in as a single comma-separated string.

The MemberId key is applied automatically. The returned value is a Map with all field values, as per a Data List

For example:

${MySheet[1].preference} - returns the preference field from the record with a key value 1 for the passed-in Member

${MySheet['keyValue1,keyValue2'].highScore} - returns the highScore field from the record based on a composite key, where the key values are keyValue1 and keyValue2, for the passed-in Member.

Orders, Surveys etc.

To be documented...

Member related special variables

If the Member is not known, these variables return null

_memberId. Returns the internal Member Id.

_me. Alias for _members. Returns the Members record.

_isMemberNew. This boolean variable is set by Forms only, and returns true if the Form ended up creating a new Member. This is handy for any triggers associated with the Form, to for example determine if a Welcome email should be sent or not.

_isNew. Set to true if the last operation created a new entry/record, false if it updated or deleted an existing record. This is handy for triggers, who should only be executed for new or modified records. For example if the Member enters a Survey, there may be a need to run different triggers depending on if it was the first or a repeated entry.

Entity Variables that don’t require a Member

These variables work even in situations where the Member is not known, such as run-if expressions for background Jobs.

Property Sheets

Returns a Map with all properties and their values.

For example: ${WebsiteSettings.domainName}

DATA Sheets

Returns a Map with the key being the table key. If composite keys, they need to be passed in as a comma-separated string, The returned value is a Map with all field values.

It works the same way as for Member Sheets, but the MemberId is not automatically used as a key.

For example ${CalendarSheet['2024,12,31].is_holiday} - assumes a Data Sheet called CalendarSheet with three keys, yer, month and day, and with a boolean column called is_holday

Special variables that don't require a Member

These special variables work even when there's not a Member.

_in

Gives access to any data or model attributes that were passed in to the API end-point, script or trigger.

Returns a Map of all passed in Model or Data attributes. The content is case dependant and differs between API endpoints.

Note that the _in variable can often be left out. The scrip engine will try the input model if it doesn’t find any other matches. However, this is needed if there is an Entity with the same name as the model attribute.

For example (a run-fi expression for a Survey): _in.feeling ='GREAT' - would only accept the survey entry if the answer to the feeling question is 'GREAT'

_out

Only available to triggers and only for some Entities and operations. The content is specific to each type of endpoint.

Gives triggers access to the output of an operation, for example a new generated primary key, an issued code or a high-score position.

_dim

Gives access to the passed in dimensions.

For example ${_dim.country = 'SV' && _dim.language = 'Swedish' ? "Hej" : "Hello"}

_ent

Returns a Map with all installed Entities. Pass in the Entity's id or name as key to the Map to expose certsin configuration fields for the Entity. This is usually used for accessing CMS fields defined in a different Entity.

For example: ${_ent.GlobalCMSSettings.cms.headerText} (or _ent['GlobalCMSSettings'].cms.headerText) - looks up an Entity called GlobalCMSSettings, and looks at the cms content and grabs the cms attribute headerText.

Note that all CMS content is processed and personalised (in case it contains scripts or localisations) before it's returned.

_this

Returns the Entity running the script. This exposes certain Entity Configuration attributes, such as bizId, state etc.

The most common scenario is probably to look up CMS field values.

For example ${_this.cms.headerText}

Note that for triggers, this is the trigger’s entity rather than the Entity in which the trigger is defined.

Note, _this is short for _ent.

_parent

Available to triggers only, and returns the Entity that contains the trigger. The attributes available are the same as for _this and _ent.

_cms.

Gives access to this Entity’s parsed cms attribute values. This is an alias for _this.cms.

_user

Gives access to the API User which is executing the script. The available User attributes are:

_user.userId

Returns the internal NEON userId. This is normally only used when logging who carried out or saved a particular record.

_user.email

If exists, returns the email address of the current User.

_user.roles

Returns a Map of the User's Roles. This can be used for additional security checks in RunIf expressions.

For example (run-if expression): _users.roles['CUSTOMER_CARE_ADMIN'] - will only allow the operation if submitted by a customer care administrator.

_neon

Gives access to certain NEON installation variables, including:

_neon.space - the name of the space
_neon.environment - the name of the environment, such as QA and PROD. This enables different scripts, triggers and logic to be used based on the environment.
_neon.appname - the name of the application running

_env

Gives access to a limited set of installation environment variables. Special security restrictions apply.