Supported InRule Features

  • Updated

Not all InRule features are available to InRule for JavaScript. Here is a list of the features that are included.

Rule Sets

The following Rule Set types are supported:

  • Explicit Rule Sets
  • Auto Single-Pass Sequential Rule Sets

Note: Auto Optimized Rule Sets and Auto Sequential Rule Sets are NOT supported.

Rule Constructs

The following rule constructs are supported:

  • If Then
  • If Then Else
  • For Each
  • While
  • Decision Table
  • Language Rule


The following rule constructs and actions do NOT support versions:

  • If Then
  • If Then Else
  • While
  • Decision Table
  • Language Rule
  • Set Value Action
  • While Rule
  • Calculation Field

Note: Inline Tables do support versions

Rule Actions 

Below are the rule actions and their corresponding support in the JavaScript rules engine.

Action Supported
Set Value Yes
Execute Rule Set Yes
Declare Variable Yes
Map Data No
Fire Notification Yes
Set Field Invalid Yes
Execute SQL Query Yes with limitations
Execute XPath Query No
Execute JavaScript Function Yes
Execute Method No
Execute Web Service No
Execute REST Service No
Execute Workflow No
Send Mail No
Refresh Fields No
Halt Rule Set Yes
Activate Rule Set No
Deactivate Rule Set No
Activate Rule Sets by Category No
Deactivate Rule Sets by Category No
Add Collection Member Yes
Remove Collection Member Yes
Clear Collection Yes
Copy Collection Yes
Sort Collection Yes
Execute Member Rule Set Yes
Copy Entity No


Note: The "Deep copy" option for the Add Collection Member and Copy Collection actions are NOT supported in the JavaScript rules engine.

Data Access

  • Inline Tables are supported.
  • SQL Queries are supported, but only against Inline Tables and SQL Queries that target Inline Tables.
  • Execute SQL Query Actions do not support "auto-mapping" of fields. There must be explicit field mappings in the "Settings..." menu.
  • Inline Value Lists are supported, but fields bound to Inline Value Lists are not supported.


Below are the functions and their corresponding support in the JavaScript rules engine.

Action Supported
Abs Yes
AddDays Yes
AddHours Yes
AddMilliseconds Yes
AddMinutes Yes
AddMonths Yes
AddSeconds Yes
AddWeekdays Yes
AddYears Yes
AllAreFalse Yes
AllAreTrue Yes
AnyAreFalse Yes
AnyAreTrue Yes
Average Yes
BankRound Yes (see below)
BuildDate Yes
Chr Yes
CollectionLookup Yes
Concat Yes
Contains Yes
Count Yes
CurrentContext Yes
Day Yes
DayDiff Yes
DayOfWeek No
DayOfYear No
DaysInMonth Yes
DaysInYear No
Divide Yes
EndsWith Yes
EqualTo Yes
EscapeJson Yes
EscapeXml Yes
Eval No
Exp Yes
Format No
FV Yes
GetAttribute No
GetDefault No
GetElementId No
GetEntityId No
GetEntityName No
GetFieldValueList No
GetFirst Yes
GetFirstValue No
GetIndex Yes
GetLast Yes
GetLastValue No
GetLocalDateTime No
GetMember No
GetMemberByIndex Yes
GetMemberValue Yes
GetMemberValueByIndex No
GetName No
GetUnspecifiedDateTime No
GetUtcDateTime No
GetValueList No
GetXPath No
GreaterThan Yes
GreaterThanOrEqual Yes
HasWhitespace Yes
Hour Yes
HourDiff Yes
If Yes
IfCase Yes
IfChain Yes
Instr Yes
InvokeEntityMethod No
IsBetween Yes
IsClassification No
IsDate Yes
IsDateTime Yes
IsInvalid Yes
IsInValueList Yes
IsLeapYear Yes
IsLocalDateTime No
IsMatch Yes
IsNotNullOrEmpty Yes
IsNull Yes
IsNumeric No
IsRegexMatch Yes
IsUnspecifiedDateTime No
IsUtcDateTime No
IsValid Yes
IsWeekday Yes
IsWeekend No
IsWildcardMatch No
JsonLookup Yes
Largest Yes
Left Yes
Length Yes
LessThan Yes
LessThanOrEqual Yes
Log Yes
Lookup No
Max Yes
Mid Yes
Millisecond Yes
MillisecondDiff Yes
Min Yes
Minus Yes
Minute Yes
MinuteDiff Yes
Mod Yes
Month Yes
MonthDiff Yes
Multiply Yes
NoneAreFalse Yes
NoneAreTrue Yes
Not Yes
NotEqualTo Yes
Now Yes
NumberOfFalse Yes
NumberOfTrue Yes
NumDigits No
NumFracDigits No
NumIntDigits No
Or Yes
OuterContext Yes
Percent Yes
Plus Yes
Power Yes
ProperCase Yes
PV Yes
QueryToList No
Random Yes (see below)
Rate Yes
RegexReplace No
RegexSelect No
Replace Yes
Right Yes
Round Yes (see below)
RoundDown Yes
RoundUp Yes
Safe Yes
Second Yes
SecondDiff Yes
Smallest Yes
SqlQueryValue No
Sqrt Yes
StartsWith Yes
Sum Yes
TableLookup Yes
ToBool Yes
ToDate Yes (see below)
ToDateTime Yes (see below)
Today Yes
ToInnerXml No
ToInt Yes
ToJson No
ToList No
ToLower Yes
ToNumber Yes
ToString Yes
ToTime Yes (see below)
ToUpper Yes
ToValueList Yes
ToXml No
Trim Yes
TrimWhitespace Yes
ValueListLookup No
WeekdayDiff Yes
XmlLookup No
Xor Yes
Year Yes
YearDiff Yes



The precision of Decimals in JavaScript rule engine is different than in the .NET rule engine. The .NET rule engine uses System.Decimal data types, whereas the JavaScript rule engine uses JavaScript's Number data type. The JavaScript Number data type conforms to the IEEE 754 floating point standard, which is equivalent to the Double data type in .NET.

Decimal arithmetic calculations within the JavaScript rule engine that encounter a NaN, Positive Infinity, or Negative Infinity will result in a runtime error.

Complex math functions such as Sqrt, Exp, and Power use the JavaScript Math object with the native Number data type, which is equivalent to the System.Math object used by these functions in the .NET rule engine.

The Round and BankRound functions only support precision up to 15 digits.

The Mod function uses the IEEE modulus algorithm. Since some decimal numbers cannot be represented exactly in binary form, some calculations involving decimal values will give slightly different results in JavaScript.


InRule Integers are also represented by JavaScript’s Number data type.

The Number data type cannot represent every contiguous integer value between the range of .NET’s Int64.MinValue to Int64.MaxValue due to the precision limitations of the floating point algorithm, however it may represent some values outside this range.

This means that large positive or negative numbers (above approximately 2^53) may not be represented as a contiguous set of numbers.

For example:

9007199254740992 + 1 == 9007199254740992

9007199254740992 + 2 == 9007199254740994

9007199254740992 + 3 == 9007199254740996

The Random function will return random integer values larger than 2147483647 without producing the same overflow error that would occur in .NET.

NOTE: Although JavaScript supports much larger integer values than .NET, the Random function argument range has been restricted between -999999999999999 and 999999999999999 to circumvent potential precision issues as a result of how numbers are stored in JavaScript.

Dates / DateTimes

InRule Dates and DateTimes are represented by JavaScript’s Date object.

In the .NET rule engine, the origin value for Dates and DateTimes (from numeric 0, boolean false, empty string, or null) is 1/2/0001; in JavaScript we are using the UNIX epoch 1/1/1970 in the local timezone.

Parsing Dates and DateTimes only supports the following formats.

  • ISO 8601                     (e.g. 2016-03-24T21:33:55.123)
    • Milliseconds time component may only be 1 to 3 digits in length, and is optional (e.g. 2016- 03-24T21:33:55.1, 2016-03-24T21:33:55)
    • Seconds time component is optional (e.g. 2016-03-24T21:33)
    • Supports date-only (e.g. 2016-03-24)
    • All Dates are parsed in the local timezone
    • DateTimes are parsed in the local timezone unless an optional timezone suffix is provided:
      • 2016-03-24T21:33:00                      -> parsed in local timezone
      • 2016-03-24T21:33:00+01:00           -> parsed in the timezone specified (and converted to the local timezone)
      • 2016-03-24T21:33:00Z                   -> parsed in UTC (and converted to the local timezone)
  • RFC 2822                   (e.g. Thu, 24 Mar 2016 21:33:55)
    • Milliseconds time component is not supported
    • Seconds time component is optional (e.g. Thu, 24 Mar 2016 21:33)
    • Supports date-only (e.g. Thu, 24 Mar 2016)
    • Comma after the day name is optional (e.g. Thu 24 Mar 2016)
    • Day name is options (e.g. 24 Mar 2016)
    • All Dates are parsed in the local timezone
    • DateTimes are parsed in the local timezone unless an optional timezone suffix is provided: 
      • 24 Mar 2016 21:33                             -> parsed in local timezone
      • 24 Mar 2016 21:33 -0500                   -> parsed in the timezone specified (and converted to the local timezone)
  • en-US short date-time          (e.g. 3/24/2016 9:33:55 PM)
    • Milliseconds time component is not supported
    • Seconds time component is optional (e.g. 3/24/2016 9:33 PM)
    • 12-hour format time period suffix may be lower case (e.g. 3/24/2016 9:33 pm)
    • Supports 24-hour format (e.g. 3/24/2016 21:33)
    • Supports date-only (e.g. 3/24/2016)
    • All Dates and DateTimes are parsed in the local timezone
    • No timezone suffix is valid

The valid range for the years component for all formats is 0001 to 9999.

Parsing an invalid Date or DateTime will result in throwing an error through the SDK, or causing a runtime error to occur during rule execution.

Formatting a Date or DateTime will always output using the en-US short date or short date time format. This may be round-tripped by parsing the output, however since no timezone information will be formatted, the Date / DateTime must be assumed to be in the same local timezone.


InRule Strings are represented by JavaScript’s String data type.

JavaScript strings are Unicode as are .NET’s System.String, therefore they should be able to represent the same characters.

JavaScript string comparison behaves differently than .NET’s string comparison due to the limited and inconsistent Internationalization (i18n) functionality.

Most modern web browsers and node.js now include support for the ECMA-402 Internationalization API which exposes the Intl.Collator object.

Unfortunately not all web browsers support this object (Apple’s Safari browser does not support it at the time of writing) and those that do, do not support it consistently. Microsoft’s Internet Explorer and Edge browsers will produce different comparison results than Firefox and Chrome without adjusting the Collator’s options.

String comparisons involving less than or greater than operators in InRule syntax expressions are possible but not particularly useful (e.g. “Apple” < “Banana”). It becomes more useful when used with the Sort Collection action to sort a collection on a text Field to provide alphabetical sorting.

Due to the inconsistency in comparison functionality, Strings are compared using their ordinal Unicode value, as opposed to any culture/locale comparison rules.


InRule Booleans are represented by JavaScript’s Boolean data type.

Boolean functionality should be identical to the .NET rule engine’s Booleans.

Was this article helpful?

0 out of 0 found this helpful



Please sign in to leave a comment.