Detailed Function Descriptions

The following sections provide detailed descriptions of certain functions.

Verifying User Security Roles

Some situations may change depending on the type of user working in the system.  The following functions are used to determine if the current user has a specific security role.

For use in the policy module:

$UserContainsRole(UserRole)

Where UserRole is the Name of the security role as it appears in the system.

For use in the claims module:

UserContainsSecurityRole(UserRole)

Where UserRole is the Code of the security role.

The functions return “True” if the user has the role, or “False” if they do not.  The result can be used in a conditional formula, or as a condition within a trigger.

Compare Data Against Sanction or Watch Lists

With the potential consequences of violating international restrictions, it can be very important to validate data and ensure that it is in compliance with regulations.  The Compliance() function allows one or more fields to be compared to one or more sanction or watch lists from around the world.

Comparing a Field Against a Single List

Compliance([[ScanField]],List)

Where ScanField is the field to be scanned and List is the code of the list.

Comparing a Field Against Multiple Lists

Compliance([[ScanField]],List1,List2,List3)

Where ScanField is the field to be scanned and each List# is the code of a list.  Any number of lists can be included.

Comparing Multiple Fields Against Multiple Lists

Compliance([[ScanField1]] [[ScanField2]][[ScanField3]],List1,List2,List3)

Where ScanField# are the fields to be scanned and each List# is the code of a list.  The scan fields are combined and scanned as one large block of text, which is why a space should be added between each field to prevent the text from flowing together.

This function outputs a numerical value from 0 (no match) to 100 (perfect match).  If a different score is achieved on different lists, the highest score is returned.

See Sanction and Compliance Lists for a table of all lists and their associated codes.

Identifying When Fields Have Changed After an Integration

Transaction workflows may contain integration configurations that share data with external systems.  In some cases, such as when the integration scans data for security concerns, it is important to know if the user has made changes to certain fields since the last time the integration was run.

This section describes how to assemble the necessary fields and configurations to identify such changes.

Note: It is recommended to use the DetectChanges() and ModifedOn() functions for any new configurations. See the function descriptions in the Full Function Reference List for details.

Overview:

Once configured, each time the calculated fields in a transaction are recalculated, the HashAndModifiedOn() function evaluates the tracked fields and generates a composite value derived from those fields.  The first time the function runs within a transaction, it stores the composite value (the Hash value) and the current date and time.

Each time it runs after the first time, the function recalculates the composite value and compares it to the stored value.  If the value has changed, the old composite value is replaced with the new value and the date and time are updated to the current date and time.  Note that this stores the date and time the changes were detected by the function, and not when the changes actually occurred.

In the background, whenever an integration is completed successfully, the system stores the date and time the integration was performed.  Each different integration configuration is tracked separately, so the most recent date and time information is available for each.  These dates and times can be retrieved using a calculated field, providing a reference date to determine if the data was changed since the last time the integration was performed.

With the date of the integration, and the date that changes were detected in the tracked fields, the IsDateGreaterThan() function is used to compare the dates.  If the tracked fields were changed after the last integration, the function returns "True".  This result can be used in a trigger to re-run the integration, activate a validation, or affect any other feature that uses the trigger.

Configuration:

1. Identify and create the necessary fields.

   Tracked Fields	These are the fields that will contain the data that will be monitored for changes.  These fields may already be part of the workflow, or may be new fields created specifically for tracking.  All field types can be tracked.
   	Caution: Use caution when tracking fields that may be changed by the integration.  That change will be detected and trigger the integration again, creating a loop.
   Hash Reference Field	This field will contain the generated composite value from the HashAndModifiedOn() function.  This should be a Text Area field with no default value.
   Detected Changes Timestamp Field	This field will contain the date and time that the HashAndModifiedOn() function detected changes to the tracked fields.
   Hash Function Field	This field will contain the HashAndModifiedOn() function.  This should be a standalone Text Area field containing just this function.
   	HashAndModifiedOn(p0, p0, p0, ..., p1, p2)
   	P0: Placeholders for all Tracked Fields to be included in the hash calculation should be provided, separated by commas.
   	P1: The Code of the Hash Reference Field must be the second-to-last parameter after all of the tracked fields.  This condition is literal and must contain the Code of the field without any square brackets, no placeholders or functions can be used here.
   	P2: The Code of the Detected Changes Timestamp Field must be the last parameter. This condition is literal and must contain the Code of the field without any square brackets, no placeholders or functions can be used here.
   	Example: HashAndModifiedOn([[tracked field 1]], [[tracked field 2]], [[tracked field 3]], HashReferenceFieldCode, DetectedChangesTimestampFieldCode)
   Date Comparison Field	This field retrieves the date of the integration and compares it to the last detected changes date from the HashAndModifiedOn() function.  This field  will resolve to "True" if changes are detected after the integration, or "False" if no changes are detected.
   	IsDateGreaterThan(p0, p1, p2)
   	P0: Placeholder for the Detected Changes Timestamp Field.
   	P1: Placeholder containing the date and time the relevant integration was last completed successfully.  The following placeholder can be placed directly in the function, or can be included in a calculated field that is then referenced in the function.
   	If using a field, a Date Picker field should not be used or the time component will be lost.  A Textbox field should be used.
   	[[Integrations/Integration[Code='code']/StartTime]]
   	The code should be the code of the integration configuration defined for the workflow.
   	P2: Tolerance in milliseconds.  The system date/time format is accurate to a ten-millionth of a second.  Even dates that seem to be calculated at the same time will have a small difference.  If the P0 date is only greater than the P1 date by less than the provided tolerance, it will not be considered a difference and the function will return false.
   	Example: IsDateGreaterThan([[Detected Changes Timestamp Field]], [[Integrations/Integration[Code='IntegrationConfigurationCode']/StartTime]], 1000)
   	With this configuration having a tolerance of 1000 milliseconds, if the Detected Changes Timestamp Field date is earlier than the integration timestamp or less than one second after, it will not be considered a change.
   Integration Flag Field	If the relevant integration has not yet been performed, the IsDateGreaterThan() function will try to compare the Detected Changes Timestamp Field with a non-existent date, and return an incorrect "true" value.
   	This field can be any type of field, but must be updated by the relevant integration when it runs.  Any triggers created to detect the changes should also check this field to confirm the integration has been performed at least once in the current transaction.

   Tip: Any of the fields used in this configuration can be hidden.  Since many of the fields will only contain raw data used in the functions, it is probably best to hide them.

2. Once the fields have been configured, the results can be used in triggers.  The trigger conditions should check the Date Comparison Field for a true result (Field - Equals - 1) AND the Integration Flag Field should equal the value inserted by the integration.
3. The triggers can then be used to reactivate the integration or for any other controls.

Interpolation/Extrapolation

The process of interpolation or extrapolation involves taking a known set of paired values, like the x and y-values of points in a grid, and determining unknown y-values from known x-values.  Determining values within the known range is called interpolation, while determining values beyond the known range is called extrapolation.

The $InterpolatedLookup() function takes a lookup table already defined in the system as the known set, and will interpolate or extrapolate a value of y for a specific value of x.

The function is constructed as follows:

$InterpolatedLookup(p0,p1,p2)

P0 (text): The Code of the table containing the data.  The first column of the table must be a numeric column to be used as the y-values.

P1 (text): The name of the column containing the x-values.  This must be a numeric column with unique values.

P2 (numeric): The x-value for which to calculate the y-value.

The function sorts the points by the x-values in the P1 column, and then finds the two points nearest to the x-value provided as P2, shown as the dotted vertical line in the examples below.  For x-values within the known range, the function finds the closest points above and below the x-value.  For x-values lower than the known range, the function finds the two points with the lowest x-values, and for values higher than the range, it finds the two points with the highest x-values.

Those two points are used to determine a linear rate of increase or decrease, shown as the dashed line in the examples below.

The point where the dashed line crosses the dotted line is the interpolated or extrapolated point.  The value of y at that point is determined using the following calculation.

Where (x¹, y¹) and (x², y²) are the two nearest points.

The calculated value of y is then returned by the function.

Some exceptions exist:

• If the P2 value exactly matches an x-value in the P1 column, the function returns the associated y value.
• If the table only contains one row of data, interpolation/extrapolation is not possible.  The function will return the single y-value.
• If the P0 lookup table is empty, the function will return 0.

Custom Date Format Function

While there are several functions to format dates, sometimes a date needs to be presented in a very specific manner.  The Custom Date Format function uses formatting codes that can be mixed and matched to provide an exceptional level of control.

The function is constructed as follows:

CustomDateFormat(Date,"{0:Code}")

Date is the date to be formatted.  This can be a constant value or a placeholder.  The date must be provided in the full system date format, such as "2016-06-15T14:55:22.1234-04:00".  Date picker fields automatically save the date in this format.

Code is the formatting code.  See the table of codes below.  Some codes must be used alone, while others can be combined.

The formatting code can be pulled from a placeholder. There are two ways to achieve this.

• With the function CustomDateFormat(Date,[[CodeField]]), the Code Field must include the full {0:Code} notation.  The quotes are not required within the Code Field.  If the [[CodeField]] is empty, the function will not return any results.
• With the function CustomDateFormat(Date,"{0:"[[CodeField]]"}"), the Code Field only needs to contain the Code.  If the [[CodeField]] is empty, the code will default to G.

Codes:

The following are pre-formatted codes that cannot be combined with other codes.

All examples are from the source date "2016-06-15T14:55:22.12-04:00".

The following are component codes that can be combined to form a custom date format.  Components can be divided by spaces, slashes, colons, commas, or periods.

All examples are from the source date "2016-06-15T14:55:22.12-04:00".

Functions to Enter Data Into Grids (Automatic Grid Processing)

While there are multiple ways to enter data into a grid, they generally require user input.  Calculated fields can be used to enter data into grids, either as static values or copied from other fields or grids within the workflow.  The functions can add rows, edit or replace existing rows, or clear the grid and start fresh.

The first function is ClearGrid(), which deletes all rows from a grid, as well as any associated child grids.

ClearGrid(p0)

The two functions for copying rows are SaveToGrid() and NewGrid(), and use the same parameters.  The difference is that SaveToGrid() adds new rows after any existing rows, while NewGrid() deletes any existing rows and adds new rows to the empty grid.

SaveToGrid(p0, p1_SequenceNo, p2, p3, p4, p3, p4, …, copies, p5)

-or-

NewGrid(p0, p1_SequenceNo, p2, p3, p4, p3, p4, …, copies, p5)

Note: Without controls, the grid mapping will occur every time the calculated field is evaluated.  This can result in unnecessary processing, duplicate data, or data loss if the grid is cleared after being edited.

The best way to control the processing is to isolate each function within its own calculated field, which can be hidden in the workflow.  The function fields must have the Always Calculate option unchecked, or they will be activated each time the system evaluates calculated fields.  Another calculated field can then be set to call the function fields from within a conditional structure.

Due to the method used to process multiple rows, the entire calculated field is re-evaluated for each row combination in the source grids, even if a conditional structure prevents the grid mapping functions from creating new rows.  This can result in repetitive processing of other functions or calculations in the field.  This can be avoided by moving any extra calculations to other fields that will be called before or after processing the grid mapping functions.

Basic Processing of Standalone Grids

By default, the SaveToGrid() and NewGrid() functions process every row in the source grids, and consider any child grids as separate grids.  This section describes this default functionality.

For details on other options, see the Conditional Processing of Standalone Grids and Processing Parent and Child Grids sections.

If all p4 source fields are within form panels in the primary workflow, known as top-level fields, the functions create one row in the target grid.

If one or more grid fields are used as p4 source fields, the behavior depends on the configuration.

• If all grid fields are from the same grid, one new row is created in the target grid for each row in the source grid.
• If the source fields are from two or more separate grids, one new row is created in the target grid for each possible combination of the source rows.  The number of new rows will equal the number of rows in the first grid, multiplied by the number of rows in the second grid, multiplied by the number of rows in the third grid, and so on.  Only rows are multiplied, so taking multiple fields from a single grid will not increase the number of new rows.

For example:  With three grids, each with two rows, the following new rows are created.

Grid 1 Row 1	Grid 2 Row 1	Grid 3 Row 1
Grid 1 Row 1	Grid 2 Row 1	Grid 3 Row 2
Grid 1 Row 1	Grid 2 Row 2	Grid 3 Row 1
Grid 1 Row 1	Grid 2 Row 2	Grid 3 Row 2
Grid 1 Row 2	Grid 2 Row 1	Grid 3 Row 1
Grid 1 Row 2	Grid 2 Row 1	Grid 3 Row 2
Grid 1 Row 2	Grid 2 Row 2	Grid 3 Row 1
Grid 1 Row 2	Grid 2 Row 2	Grid 3 Row 2

• If the source fields are from a parent grid with one or more child grids, one new row is created for each parent/child/grandchild combination.  Only rows are multiplied, so taking multiple fields from a single grid will not increase the number of new rows.

For example:  For a parent grid with one child grid, where the first row in the parent has three child rows, the second parent row has two child rows, and the third parent row has one child row, the following new rows are created.

Grid 1 Row 1	Grid 2 Row 1
Grid 1 Row 1	Grid 2 Row 2
Grid 1 Row 1	Grid 2 Row 3
Grid 1 Row 2	Grid 2 Row 1
Grid 1 Row 2	Grid 2 Row 2
Grid 1 Row 3	Grid 2 Row 1

• If any top-level source fields are mixed in with grid sources, the value of the top-level field is repeated in each row resulting from the grid combinations.  If the top-level field contains multiple values, such as a checkbox group, all selected values are combined into one value and repeated in each new row.

When using p1 and p2 to update a specific row, only one value can be inserted into each field.  For this reason, updates are best performed using top-level fields.  To use a grid value, the formula must use a conditional structure that returns a single value from the grid.

After being evaluated, both functions return the row numbers that were added or edited.

Conditional Processing of Standalone Grids

By default, the SaveToGrid() and NewGrid() functions process every row in the source grids, and consider any child grids as separate grids.  This section describes how the Where() function can be used to apply conditions that omit individual values or entire rows.

For details on other options, see the Basic Processing of Standalone Grids and Processing Parent and Child Grids sections.

Both the SaveToGrid() and NewGrid() functions can be used to copy data from specific rows in the source grid.  The Where() function applies a condition that is evaluated for each row in the source grid.  If the condition evaluates to True, the row or value is processed, and if it evaluates to False, the row or value is skipped.  The placement of the Where() function affects the results, as shown below.

• Placing the Where() function outside of the grid function applies to the entire function, causing it to skip entire rows.

For example, a source grid has the following data.

Source Grid
Field 1	Field 2	Number
Row 1 Field 1	Row 1 Field 2	5
Row 2 Field 1	Row 2 Field 2	14
Row 3 Field 1	Row 3 Field 2	9
Row 4 Field 1	Row 4 Field 2	20

The following formula is used.

NewGrid(TargetGrid,

   TargetGridField1, [[SourceGridField1]],

   TargetGridField2, [[SourceGridField2]],

   TargetGridNumber, [[SourceGridNumber]])

Where([[SourceGridNumber]] > 10)

The Where() function evaluates if the value in the Number field is greater than 10, which produces the following content in the target grid.

Target Grid
Field 1	Field 2	Number
Row 2 Field 1	Row 2 Field 2	14
Row 4 Field 1	Row 4 Field 2	20

• Placing the Where() function inside the grid function applies to the preceding parameter.  The grid function will process all rows, but the optional value will only be included if the condition evaluates to True.

For example, a source grid has the following data.

Source Grid
Field 1	Field 2	Number
Row 1 Field 1	Row 1 Field 2	5
Row 2 Field 1	Row 2 Field 2	14
Row 3 Field 1	Row 3 Field 2	9
Row 4 Field 1	Row 4 Field 2	20

The following formula is used.

NewGrid(TargetGrid,

   TargetGridField1, [[SourceGridField1]],

   TargetGridField2, [[SourceGridField2]],

   TargetGridNumber, [[SourceGridNumber]] Where([[SourceGridNumber]] > 10))

The Where() function evaluates if the value in the Number field is greater than 10, which produces the following content in the target grid.

Target Grid
Field 1	Field 2	Number
Row 1 Field 1	Row 1 Field 2
Row 2 Field 1	Row 2 Field 2	14
Row 3 Field 1	Row 3 Field 2
Row 4 Field 1	Row 4 Field 2	20

Note: Care should be taken when applying conditions to parameters.  Using Where to omit a required parameter will result in an error.  However, two versions of a required parameter can be provided with conditions that use one version or the other (do not include additional commas).

Processing Parent and Child Grids

By default, the SaveToGrid() and NewGrid() functions process every row in the source grids, and consider child grids as separate grids.  This section describes how the Where() function can be used to copy grids with child grids, maintaining the associations.

For details on other options, see the Basic Processing of Standalone Grids and Conditional Processing of Standalone Grids sections.

Copying rows from a parent grid and child grid is a two-step operation.  The first step copies all rows in the parent grid, assigning the row numbers in the process.  The next step conditionally copies the rows in the child grid, matching the parent row number from the source grid to the parent row number in the target grid.

The functions for the parent copy and child copy should be kept in separate calculated fields, and called one after the other from a third field, such as "[[CopyParentGrid]] [[CopyChildGrid]]".  If the two functions are not activated together like this, there is a chance that the parent data could be modified before the child data is copied, resulting in mismatched data.

1. The Parent Copy function:  The parent copy can be performed using the same basic processing or conditional processing methods detailed above.  However, the row numbers must be tracked to allow the child copy function to associate the correct child grid rows to each parent.

The [[GridCode_SequenceNo]] placeholder can be used to reference the internal row numbers in the grid.  When copying all grid rows from a source grid to an empty target grid, the row numbers will match.  However, if the copy is conditional or if the target grid is not empty, the row numbers will likely not match up and the child copy will associate the incorrect rows.  The best practice in all cases is to add an extra field to the parent target grid, perhaps named "SourceRowNumber" or something similar, and copy the row numbers into this field along with the rest of the parent data.  This extra field can be set to read-only, and hidden in the workflow.

2. The Child Copy function:  The child copy function is similar to the conditional processing method detailed above, except that the condition specifically uses row numbers to associate the child rows to the correct parent rows.

Without the condition, the child copy would copy all rows in the source child grid for each row in the target parent grid.  With the condition, the system still evaluates all rows in the source child grid for each row in the target parent grid, but leaves out any child rows that do not match the current parent.

The Where() function should be outside of the grid function, and should be formatted as shown below.

NewGrid(TargetChildGrid,

TargetChildGridField1, [[SourceChildGridField1]],

etc…)

Where([[TargetParentSourceRowNumber]]= [[SourceParent_SequenceNo]])

This compares the [[TargetParentSourceRowNumber]] copied by the parent copy function to the [[SourceParent_SequenceNo]] from the original parent grid, and only copies the child rows belonging to the current target parent row.

Tip: This method can also be used when loading static data into child grids, rather than copying data from another child grid. As long as the Where clause is used to reference rows in the parent grid while saving data to the child grid, the system will automatically create the associations to the parent rows.

Inserting Additional List Data

When copying data into a grid, it may be necessary to add additional information that is not part of the source tables. The NewList function allows a series of values to be included in the formula, whether they are static values, calculated values, or data pulled from fields. These values will be included in the processing of the source grid values, and can even be managed with conditional controls.

The NewList function is formatted as follows.

NewList(p0,…)

The p0 parameters include all of the list values, separated by commas.

The function returns the values as a list, formatted for use in other functions. When used as the p4 parameter in a NewGrid or SaveToGrid function, this list will be processed as if it were another source grid.

Note: Since the list is processed as an additional source, the duplication rules for multiple grids will apply. This means that any rows from preceding grids will be repeated for each value in the list, and the entire list will be repeated for each row of any subsequent grids.

Dividing String Values Into Rows

When copying large data fields into grids, it may be necessary to break the content up into smaller pieces. The BreakText function can be used to break the large string into smaller strings with a set maximum length, then copy the smaller strings into separate rows.

The BreakText function is formatted as follows.

BreakText(p0,p1)

The p0 parameter identifies the text to be split. This can be a placeholder, function, formula, or literal value.

The p1 parameter defines the maximum number of characters in the sub-strings. If the character number falls in the middle of a word, the system will move back to the nearest whitespace, such as a space, tab, or line break character. If a single word exceeds the maximum number of characters, the word will be split at the character limit.

The function returns the string pieces as a list, formatted for use in other functions. When used as the p4 parameter in a NewGrid or SaveToGrid function, this list will be processed as if it were another source grid.

Note: Since the list is processed as an additional source, the duplication rules for multiple grids will apply. This means that any rows from preceding grids will be repeated for each string piece in the list, and the entire list will be repeated for each row of any subsequent grids.

Converting Multi-Value Fields Into Rows

When copying Include Exclude List or Multi Select field data into a grid, the data is treated as a pipe-separated string by default. The ExtractItems() function can be used to divide the selected values into individual rows, which can then be processed by the grid management functions.

The ExtractItems() function is formatted as follows.

ExtractItems(p0)

The p0 parameter should be the Code of the source field, enclosed in brackets.

The function returns the selected values as a list, formatted for use in other functions. When used as the p4 parameter in a NewGrid or SaveToGrid function, this list will be processed as if it were another source grid.

Note: Since the list is processed as an additional source, the duplication rules for multiple grids will apply. This means that any rows from preceding grids will be repeated for each string piece in the list, and the entire list will be repeated for each row of any subsequent grids.

Load Transaction Data to Grids

When the option to Allow Quote Versions is enabled, alternate versions of an unbound New Business or Renewal transaction can be generated for the same policy term. All available quote options for a given transaction are displayed in the Quote Summary window, which is accessed by clicking the Quote Summary link in the Premium Widget within the submission workflow. For information about multiple quote options, see the Miscellaneous Settings panel in the Master Covers - Policy Settings section.

If it is necessary to extract, display, or otherwise compare data from multiple quote versions outside of the Quote Summary window, the LoadTransactionstoGrids() function can be used. This function uses one or more source grids configured to contain quote version data, and maps this data to one or more target grids configured within the same workflow. The relationship between source grids and target grids is one to one, which is to say that an equal number of source grids and target grids must be configured.

The LoadTransactionstoGrids() function is formatted as follows.

LoadTransactionstoGrids('TransactionTypes', p0, 'TransactionStatuses', p1, 'IncludeSourceHeaders', p2, 'SourceGrids', p3, 'TargetGrids', p4)

Example: LoadTransactionsToGrids('TransactionTypes', NewBusiness|Renewal, 'TransactionStatuses', Incomplete|Quoted, 'IncludeSourceHeaders', True, 'SourceGrids', SourceGrid|SourceGrid2, 'TargetGrids', TargetSourceGrid|TargetSourceGrid2)

Note: Any source grids configured for use within this function should contain a single row of data. This row should be empty if the version should not be included in the results. One way of achieving this is through the ClearGrid() function.

The same number of columns must be configured for each source grid and target grid pairing.

When a source grid meets criteria established by the specified Transaction Type and Transaction Status, the fields from the source grid data are mapped to the fields in the target grid according to sequence number. Gaps in the sequence numbers are accepted.

The source grid rows are displayed in the target grid in ascending order according to the quote version number.

If a source grid row does not contain any values, the details of that quote version will not be included in the target grid. All other results will continue to be sorted according to quote version number, skipping over the version that did not contain any values.

While all data types (text, numeric, etc.) are supported for use within the source grid, the data that is mapped to the target grid will be displayed according to the control type configured for the target grid cells. It is therefore recommended that the target grid be configured with the same Control Type as the source grid. If, however, 'IncludeSourceHeaders' is set to True, the Textbox control type should be used to suit string data.

Pivot Grid Data

When data is mapped from a source grid into a separate target grid, the basic column and row structure is maintained between both grids.

The PivotGrid() function allows the user to pivot the display of data in the final target grid. The source grid row data is presented vertically, and the source grid column data is presented horizontally.

The PivotGrid() function is formatted as follows.

PivotGrid(p0, p1)

Note: The number of columns in the target grid must be greater than or equal to the number of rows in the source grid.

Sorting Grid Data

While the grid controls in the system allow for the sorting and grouping of data, this only applies to that particular view of the data. The data stored in the system remains in its original order. Any feature that uses the data, such as document generation or functions, will see and process the data in that original order.

The SortGrid() function can be used to sort and subsort the data in a grid, either ascending or descending, changing the order of the data in the internal storage. Any generated documents or functions will then see and process the data in the defined order. This function does not alter the row numbers or row id values, so any features or functions that address specific rows by number or id will not be affected.

The syntax for the function is as follows:

SortGrid(p0, p1 sort order, p1 sort order, ...)

P0 (text): Code of the target grid. This must be a static code, not enclosed in brackets.

P1 (text): Code of the column to be sorted by. This must be a static code, not enclosed in brackets. If multiple columns are provided, the function processes them in the order that they are listed, subsorting on each subsequent column.

sort order (text, optional): An optional sort order can be specified after each column code. Enter ascending or asc for ascending order, or descending or desc for descending order. If no sort order is specified, the sort defaults to ascending. Placeholders can be used, allowing the order to be defined when the function is evaluated.

Returns (): N/A

Searching Across Policies

In general, policy data is isolated to a single policy and its associated transactions. Documents, e-mails, and calculated fields can only access information from the current policy, plus common system information.

The Cross-Policy Data Configurations feature can be used to create a repository for data from selected fields across policies, and even across products. This data becomes available for use in calculated fields within individual transactions, and can be used to perform comparisons or searches. For information about configuring cross-policy data, see the Cross-Policy Data Configurations section.

The Cross Policy Match functions can be used in calculated fields to search for data within a cross-policy repository.

Note: The Cross Policy Match functions use the Q-gram Index search algorithm by default. To change this to the Soundex search algorithm, please contact your Insurity representative.

There are two main function types, Match and MatchList.

• The Match functions return a simple boolean value or True or False depending on whether a match is found.
• The MatchList functions return a customizable list of matching values that can be used in other functions.

For each main type of function, there are two variations.

• The ExactMatch functions only search for data that is an exact match for the provided search value.
• The FuzzyMatch functions search for data that is similar to the provided search value, within a specified tolerance range.

Cross Policy Match Functions

The two variations of the Match functions are formatted as follows.

$CrossPolicyExactMatch(p0, p1, p3, p3, p3, ...)

$CrossPolicyFuzzyMatch(p0, p1, p2, p3, p3, p3, ...)

These functions return the following values.

• $CrossPolicyExactMatch() returns "True" if an exact match is found within the stored data. Returns "False" if no match is found.
• $CrossPolicyFuzzyMatch() returns "True" if data is found that has a percentage match score that equals or exceeds the tolerance. Returns "False" if no data matches closely enough.

Cross Policy MatchList Functions

The two variations of the MatchList functions are formatted as follows.

$CrossPolicyExactMatchList(p0, p1, p3, return=p4|p4|…, p5)

$CrossPolicyFuzzyMatchList(p0, p1, p2, p3, return=p4|p4|…, p5)

These functions return the following values.

• $CrossPolicyExactMatchList() returns all P4 values for each transaction containing an exact match for the search value. Does not return anything if no match is found.
• $CrossPolicyFuzzyMatchList() returns the top 100 P4 values for each transaction that have a percentage match score that equals or exceeds the tolerance. The values are sorted by similarity, from highest to lowest. Does not return anything if no data matches closely enough.

Tip: The MatchList functions return multiple lists of data that are likely not useable in their default form. These functions are meant to be used within other functions capable of managing the return data. The NewGrid and SaveToGrid functions are two examples.

For the NewGrid or SaveToGrid functions, the MatchList function would be used as the P4 parameter to provide the values that will be inserted into the target fields. The P3 parameter would need to have a pipe | separated list of field codes, instead of the single field code that would normally be provided. In this configuration, there can only be one P3 and one P4 parameter, since each parameter contains all of the necessary fields.

Note that the P3 parameter must include enough fields to receive all of the data being returned by the MatchList function, otherwise an error will occur.