The following information is provided as a guide to the internal implementation of scripts, for use mainly in adding support for additional languages.

Scripts receive several input parameters:

• a set of global variables including current user's record from Contacts, same as used in saved searches and formulas.
• script event source that could be on of the following:
  WEB_WORKFLOW - script is triggered by workflow while record was edited in GUI
  WEB_BUSINESS_RULE - script is triggered by rule while record was edited in GUI
  EMAIL - script is triggered when record was created from inbound email
  API - script is triggered when record was created or modified with Web Services
  TIMER_BUSINESS_RULE - when script is triggered by rule based on schedule

current record values. Permissions won't be applied either on reading or on saving. Scripts can also block user action or force user log-out. If a user record contains linked fields, then corresponding records from the linked tables are also provided. For example, if we have a record from Cases table, that contains assigned_to field= "John" which references Contacts table, then John's record from Contacts table will be also included. Only single linked records are exported, i.e. communications tables and any other multiple value LF records will not be exported. This constraint is applied for scripts on perl, .exe scripts and all other languages that interact with via .xml files.

[optional] old record values, available when script run in response to "record modified" event. This information allows a script to understand what fields were actually changed by the user, or by preceding rules-triggered actions.
Script should output:

• exit code – either in XML or as standard exit code. All other parts of output are optional. See DTD for output XML file.
• [optional] new values for record. Please note, that it is not necessary and even not recommended for some cases, like Linked Fields with multiple columns, to "copy" input records data to output. It is enough to output only the fields your script changes.
• [optional] debug message - will go to log.
• [optional] user message - will be shown to the user in the case of non-redirecting exit code - as error message if the script blocks the change or as status message in table view if change accepted by script.
• [optional] redirect-URL to redirect user browser in the case of redirecting exit code.
• [optional] report-message to store in record history to describe script actions upon the record.

More detailed description of input and output formats is provided in the next chapters.