[WorkFlow] Guided Interaction Field Validity
- Kathleen Glica
The content in this article is appropriate for: Administrators and Supervisors
SC WorkFlow offers an optional layer of validation for select fields.
By default, the validity of all fields defaults to Always, meaning that all input is processed at face value. By assigning a validity check, the field's data is subject to verification before the call can proceed (the slide's NEXT button will remain deactivated until the validity conditions have been satisfied). There are three types of validation available on select fields in SC WorkFlow.
It is assumed that a Guided Interaction (formerly known as a script) has already been created and user is logged in to SC WorkFlow (a.k.a. the scripter).
Pattern Matching
For this validation, input must match the pre-set standard coded into the SC WorkFlow platform. This feature is commonly used on the phone, email, and zip code collection fields. Setting Pattern matching validity conditions would prevent progression in the Guided Interaction when validity conditions are not met.
Available on the following fields:
Text input
Text input (multi-line)
How to configure:
Browse to the Guided Interaction Graph/ Field Settings of the selected Text input field
Click Validity
On the pop-up, click the Pattern matching dropdown and click to select one of the following options:
free text: [default option/ no pattern matching validation] Letters, numbers and the following characters are all acceptable- !@#$%^&*()_+-={}[]|\:;"'<>,.?/
email: Value should contain one or more characters, an @ symbol, followed by one or more characters, and a domain (.com, .net, .edu, etc)
Text cannot contain spaces or the following characters ^<>()[],;:"letters only: Field must contain only letters
numbers: Field must contain only numbers
phone number: Field can contain both letters and numbers, but must have a minimum of 1 number. Can also contain the following characters +.-()
NANP phone number (Only Digits): Must contain a valid North American Numbering Plan phone number. Must contain only numbers.
NANP phone number (MASK): Formatted with a US phone number input mask, which places the area code in parentheses and puts a dash after the phone number prefix (xxx) xxx-xxxx
NANP phone number (MASK+X11): Formatted with the above input mask, but will allow for area codes beginning with x11 (211, 311, 411) which can get blocked in certain situations.
postal code: Field can only contain letters, numbers, and -
postal code (US/CA): Field can only contain letters, numbers and either a 1 or a space used as a separator.
➡️ When matching a US zip code, field is limited to 10 characters when a separator is used, or 9 when it is not.
➡️ When matching a Canada postal code, field is limited to 7 characters when a separator is used, or 6 when it is not.URL: Field should be a valid URL. Does not need to contain www.
Click Update to save and close the pop-up
Zip Code Type Validation
This is a behind-the-scenes lookup process run by SC WorkFlow in order to determine whether or not the zip/postal code is a P.O. Box-only zip code.
🛑 This feature is not available on all versions of SC WorkFlow. For successful validation, it is recommended that some version of "P.O. Box" is entered into Address Lines 1, 2, or 3 (see examples below).
Available on the following fields: Address field only
➡️This is different from zip code pattern matching (discussed below)
How to configure:
Browse to the Guided Interaction Graph/ Address field/ Field settings
Zip Code Type validation is unchecked [enabled] by default
Clicking the checkbox turns the feature OFF
➡️This validation must be disabled if using a third party postal code integration
Certain zip codes have been classified as "non-deliverable" by the United States Postal service, which means that anything sent within that zip code must be sent to a P.O. Box.
Checking this box means that the zip code lookup is disabled and shipments to the address given will be processed regardless of zip code.
⚠️ Be advised that if the client uses a delivery service that does not deliver to P.O. Boxes (including UPS and some FedEx services), and this option is selected [Disabled], the shipment will be processed and sent, but may be returned to sender as undeliverable.
Only the following P.O. Box formats are recognized as valid when typed into Address lines 1, 2, or 3:
box
po box
p.o.b.
pob
pob#
p.o. box
po-box
p.o.-box
PO-Box
p.o box
pobox
p-o-box
p-o box
post office box
P.O. Box
PO Box
PO box
box 1234
Box1234
Box-1234
PO Box 1234
Condition-Based Validation
A field's validity can be determined based on the same type of Always/Never/All of the following/Any of the following rules used for Visibility and Mirroring.
Available on the following fields:
Button
Credit/debit card
Text input
Text input (multi-line)
Dynamic SKU
How to configure:
Browse to the Guided interaction Graph/ Field Settings of the selected field
Click Validity
Click the dropdown to select the Always/ Never*/ All of the Following/ Any of the Following option
Click the remaining dropdowns to configure the rest of the If condition
Click Update to save and close the pop-up
In the above example, the Button field will be deemed as valid ONLY IF the checkboxes field includes the 1pay option. "Valid" simply means that it can be clicked (to trigger an integration). In all Guided Interactions, every field must be valid before the agent can advance to the Next slide.
⚠️ Use caution when configuring this feature!
By default, all Guided Interaction fields are valid. Utilizing condition-based validation means that an agent's progress through a call is dependent on the validity of the selected fields. Validity differs from visibility, so it may be more suitable to make certain fields hidden with conditions, rather than invalid.
🤔 *Why is there an option to set the validity of a field to Never?
The above modal uses the same design for condition-based validity as for condition based visibility and condition-based mirroring. The "Never" option exists here only for the consistency of the menu options between features. It should NOT be used, as setting field validation to NEVER means that the Guided Interaction would not be able to progress, under any circumstances, once it hits the slide that has the field with this configuration.
🎉You have successfully configured validity conditions!