Applying Filtering to Data Destinations

Available on all tiers:

Essentials
Advanced
Enterprise

Contents

About

Filtering can optionally be applied to all TrueContext data destination types for more powerful and flexible handling of submitted forms and associated data. Filtering functionality allows data destinations to execute only if the filtering rules are met. Submitted data can be routed to different destinations based on the filtering rules applied. Alternatively, each Data DestinationClosed A Data Destination specifies where to send data from a submitted form. You can use Data Destinations to automate data sharing and storage, routing data to a specific service (such as email or cloud storage) in several different formats. can route the data in a different format to the same destination depending on the data submitted.

See the information on each filtering option below for common uses.

Filtering Options

To access the filtering options, first create the Data Destination, then enter the Filtering tab. Note the data destination will only execute if the data record meets ALL filter conditions configured on this page.

2019-06-06-Filtering01.png

Form Version State

2019-06-06-Filtering02.png

  • Filtering can be based on the state of the form (Active, Draft or Archived) the data record is submitted against.
  • For example, the Draft version of an “Inventory” form might have data submitted against it for testing purposes only. To avoid routing the testing data alongside production data, check only the “Active” option to exclude Draft forms from this data destination.
  • Multiple options can be selected.

Form Submission State

Custom Filter Rules

2019-06-03-FilterRulesCustom.png

The application of custom filter rules is the most powerful and flexible of the filtering options. Rules are applied to data extracted from submitted forms, allowing the data destination to execute only if a specified string is found within the specified field in the submitted form. Typical use involves matching a question response. You can also use a DREL expression to match other types of form data or metadata.

  • Match All/Match Any: If "All" is selected, all filter rules must be met for the data destination to execute. If "Any" is selected, at least one rule must be met.

    Note:This option only applies to custom filter rules. If "Match Any" is selected, the submitted form must "match any" of the custom filter rules but must still "match all" of the non-custom rules configured.

  • Input Expression: This tells the filter which data to look at. The filter can check a question response, a form name, or a submitter name, for example. The use of Data Reference Expression Language is required.

  • Filter Expression: This specifies the string to match and must be a Regular Expression. Note that the Regular Expression is considered a match if it matches any part of the input.

Info:When you configure a Data Destination as Repeatable, you can create custom Row Filter Rules for individual rows of a Repeatable SectionClosed A Repeatable Section is a subform that contains a set of related questions. The data captured is “repeating”, because the field user can complete the same subform more than once, which creates multiple entries.. This enables you to control which summary table responses the Destination executes. The topic Create Filter Rules for Individual Rows in a Repeatable Destination explains Row Filters in more detail.

Note:If configuring an exact match filter rule, remember that the filter string must exactly match; it is case sensitive and does include white space. Consequently, exact match filtering rules are best applied to dropdown and radio button questions, or questions auto-populated by a data sourceClosed Data sources, also known as "Lookups", are external sources of data that you upload or connect to TrueContext. You can reference this data in a form to populate answers or answer options. Data sources save typing, reduce errors, and make it easy to provide mobile users with only the relevant, most current data. to avoid user entry errors.

Using Special Characters in Custom Filter Rules

If using a Filter Expression with static text that has reserved characters used in regular expressions, you must escape them out using a \. For example, if you try to add a filter rule on an email destination where the filter expression is:

Billable (Contractors)

you must enter the filter expression as

Billable \(Contractors\)

Custom Filter Rule Examples

All samples below are based on the same hypothetical "Store Audit" form where a store is given a final rating. When a form is submitted, an email data destination should filter data records so that the regional manager is only sent an email if the store fails the audit.

Simple Match

If the store fails the audit, a "Fail" string is populated into a field with the unique ID "Rating."

Match Contains Exact Match
Simply type in the string to match. The below will match a response of any string that contains "Fail" -- Fail, Failed, Failing, No Fail, etc. This filter expression will only match an answer identical to "Fail" -- NOT "Failed", Failing, No Fail, etc.

Note:If configuring an exact match filter rule, remember that the filter string must exactly match; it is case sensitive and does include whitespace. Consequently, exact match filtering rules are best applied to dropdown and radio button questions, or questions auto-populated by a data source to avoid user entry errors.

Alternation ("Or") 

In the filter rule below, the destination will execute if the store receives a grade of "Poor" or "Fail" -- the vertical bar/pipe functions as "or." As with above, this is case sensitive.

Range

The filter rule below assumes that the store is "rated" on a scale of 1-9; the data destination will execute if the store receives a grade of 1, 2, 3, or 4. Note that this will only match single characters; if a 10 is entered, the "1" will match and meet the conditions of the filter.

Answer is Blank/Not Blank

Rather than testing the content of a field to determine if a data destination should execute or not, you may wish to simply test if a field has been answered or not.

If you want the data destination to execute only if there IS an answer, the expression is: ^(?!\s*$).+

If you want the data destination to execute only if the answer is BLANK, the expression is: ^\s*$