Data types can be created to validate field values against a set pattern – we call these "pattern custom field data types". Pattern CFDTs enable the system to more accurately transcribe fields where a pattern is expected – for example, an account number of two letters, followed by seven digits, with a particular separator value such as a dash or slash.
How to define a pattern CFDT
The image below is the Data Type Information page, and it is where you will configure the custom field data type, apply normalization, and add variations.
To create a new data type using a pattern:
Navigate to the Library > Data Types.
Click on the Create Data Type button in the top right of the screen.
In the modal, enter the desired name for the new data type, set the status, and then click Next.
From there, select Create a Pattern > Next.
Define the pattern for the data type one character at a time. Characters will be labeled numerically beginning with 1, from left to right.
Add additional characters using the + Add Character labeled button, which adds a character to the right of the latest character defined. Click on the character box to adjust the definition of a character. To remove a character, select the character to be removed and click Delete Character Position in the box showing the character details.
For each character, the following options are available:
Character value - alphabetical, numeric, special character. For each of these options, all of the values within the category may be selected, or just specific values. For example, only certain special characters may be desired, or only particular letters may be expected in the values for fields using this data type.
Optional - each character may also be specified as optional. For example, if an account number is expected to have two letters, followed by a dash and five to eight digits, the last three digits may be marked as optional.
If there is no need to define variations or normalization, select Create to confirm the new data type. Otherwise, follow the next steps before creating the data type.
Define normalization
Normalization is valuable in cases where the desired output is different from the input pattern defined in the custom field data type. For example, if your pattern CFDT for an account number always includes dashes and you want to exclude the dashes in output, you can handle that with normalization.
To define normalization:
Click Define Normalization in the top right corner of the Data Type Information page.
In the configuration panel, select the characters that you do not want to appear in the output (see image above for reference).
Click Save to return to the Data Type Information page.
If you do not need to create variations, click the Create button in the top right to create the new data type. Otherwise, continue to the following step.
Note that although CFDT patterns cannot be edited after creation, you can use the Copy to New Data Type function to create a new data type based on an existing one.
To learn more about the copy-to-new function, see What is a Data Type?
Pattern variations
Multiple variations may be specified for each custom pattern field data type. For example, if an account number can have either two letters followed by seven digits, or seven digits only with no leading letters, a second variation can be defined with only seven digits. In this scenario, marking the two letter characters optional in a single variation would result in a match for a value such as “A-1234567”, with only one preceding letter - so using variations provides extra specificity.
To add a variation:
Select the + button labeled Add Variation at the bottom of the page to open a new configuration panel.
To copy and edit an existing variation, instead of replicating the variation from scratch:
Select the Duplicate Variation option in the top right of the configuration panel.
Use the Delete Variation to delete the new panel.
At this point, the custom data type should be fully configured. Click the Create button in the top right to create the new data type.
Notes
Once the desired patterns have been defined, they cannot be edited.
When transcribing values on fields using pattern custom field data types, the machine’s confidence will be lower on values which do not adhere to the defined patterns. Thus, those fields will be more likely to be sent to Supervision and require human transcription.
When a field defined with a pattern custom field data type is sent to Supervision for transcription, the system will provide feedback to the keyer when the entered value does not match the defined pattern for that data type. As with other data types, the formatting restrictions on fields using pattern custom field data types can be overridden to remove this feedback.