...
- Description: A description field to provide an identifying name for this validation routine.
- Table Name: The Database table name to which this validation is be applied.
- Table Record: The specific RECID number that should be validated. Leave this blank to apply the validation to all records.
- Action: Save or Delete options specifying the table action that should be validated.
CAUTION: When creating Custom Validations, it is better to have a handful of large Custom Logic than it is to have numerous amounts of short Custom Logics defined for your Organizations Custom Validations. This is because as the number of Custom Validations that trigger on the same form increases, application performance begins to suffer, and can eventually start risking application timeouts. It is also important to ensure the same Custom Logic is not running multiple times on the same records as this also will reduce application performance if a large number of records undergo this same change at once, such as the case with any Validations that might trigger from a Service Desk Action. The performance issue originates from the delay in starting a new validation after one executes. When this delay occurs multiple times during the execution of an extended task, such as completing a large number of Service Desk Actions, this can push the process to take too long and trigger application timeouts.
Logic tab
The Logic tab is where the Custom Logic can be written and reviewed.
...
Users will be limited to the white-listed functions for PHP in PCR-360. A list of the functions can be seen in PCR-360 by clicking on the 
button.
Debug tab
The Debug tab is where any shows the results of the debug function are displayedcalls. This debug information is only available for 24 hours before it is deleted, as the only purpose is it for testing any new Custom Logic your Organization is trying to addcleared after 24 hours.
Prerequisites
This feature is intended for Administrators and an understanding of PHP language and syntax is Required. You must also be aware of language compatibility for the version of PHP installed on the webserver. For validation that requires querying other data, an understanding of SQL is necessary, particularly variants specific to your database platform.
...
Custom Validation shares a set of common syntax and available functions with the other types of Custom Logic. There are also various built-in functions to assist in querying data in order to do the lookups validations require.
...
These two functions setError() and setWarning() can have a number of different returns. In addition to the type of message set, the return will also determine behavior. The following table explains the expected results of using either function and the return values. In the table, "not-false" means any return that is not Boolean false. False-ish values (0, empty string, etc.) do not count.
Function | Return | Result |
|---|---|---|
setError() | false | Error is issued, Save or Delete fails |
setError() | not-false | Warning issued, save or delete passes |
setWarning() | false | Error is issued, save or deletefails Note: An additional generic Error line will display because a false return implies an error message should have been set and was not. Generic Message text: "A Validation Error has occurred" |
setWarning() | not-false | Warning issued, save or delete passes. |
setError() + setWarning() | false | Error issued with both messages, save or delete fails. |
setError() + setWarning() | not-false | Warning issued with both messages, save or delete passes. |
What this means is that the return dictates whether the action passes (false: no, not-false: yes)and what dialog type Users get (false: error, not-false: warning). Messages just correspond to the type of return sent.
...
When a Custom Validation is triggered during an Import the message will be output into the Imported Records grid as an Error. The message content from the Error will appear in the 'Error Description' column of the grid.
...