Step 7: Configuring Valid and Invalid Email Workflow Paths

Estimated Reading Time:  11 minutes

Introduction

In the previous use case lesson, you copied and pasted a module to validate employee email addresses. This Employee Validation module contains logic components that check the end-user End-Users are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product.'s email address for the @unqork.com company domain. In this lesson, you'll revisit the copy/pasted module and review the configuration of the Initializer, Decisions, and Hidden components to explore how the validation works.

Once your workflow validates the end-user End-Users are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product.'s email address, the copy/pasted module's Hidden component contains the valid or invalid response. An Exclusive Gateway Workflow node can then divert your workflow path to different processes based on the valid or invalid response. That means you can stop invalid email address domains from proceeding in your application while allowing valid email address domains to continue the process.

You can preview an example of this completed use case step here: https://training.unqork.io/#/workflow/64653519811f0f6e5b3c24ec/edit.

Learning Objectives

In this unit, you'll learn how the Initializer, Decisions, and Hidden components validate email addresses for a company domain. You'll learn how to use the Exclusive Gateway node to direct the end-user End-Users are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product.'s application path based on their validation response. You'll also learn how to send automated messages from your workflow using a Message node.

What You Need

To complete this step of your application, you need

Open Your Workflow Application

Start by opening your workflow application you previously created in the Workflow Editor.

1. Open your Workspace. You can find your Workspace by selecting (Search magnifying glass) and entering Creator Workshop Workspace [your name].
2. In your Workspace, select View App on your application tile. Your application title will be [initials] + “Creator Workshop App” + [date you created the application].
3. From the menu to the left of the Application page, select  Workflows.
4. Click on your Creator Workshop App workflow tile.

Email Validation Module Configuration

Once your application is open, navigate to the Email Validation module to review the logic component configuration.

To open your Email Validation module from the Workflow Editor: 

1. Select the Email Validation  Task node to open its Settings Menu.
2. Click (Expand) to expand the node Settings Menu.
3. Select  Open to open the Email Validation module in the Module Editor.

Here's what the Email Validation module looks like in the Module Editor: 

Image showing the Email Validation module. The module contains an Initializer, Decisions, and Hidden component.

Initializer Component Configuration

For an Automated task, there must exist a way to tell the configuration to begin. Because the Email Validation  Task node is in the Automated swimlane, it's an automated task thatrequires a trigger to run. In the Email Validation module, the initRuleEmailValidation Radio Button component icon Initializer component functions as this start trigger. The Initializer’s Trigger Type determines when the component will run.

Below are the available Trigger Types for an Initializer component:

Trigger Type Description

Manual

The component fires when triggered by another component (for example, a Button or Plug-In component).

Watch

The component fires when there's any action taken on the input component(s) listed in the Inputs table. Actions include entering a new value or editing or overwriting a saved value. If multiple inputs exist, use the Required setting to specify what inputs must be present before firing.
New Submission

The component fires when the page or called module loads without an existing submission ID. Dashboards and remote execute modules are great uses for this trigger.
Edit Submission

The component fires when the page loads with a submission ID.
Browser Event

The component fires when the end-user End-Users are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product. closes or refreshes their page. When this happens, the end-user End-Users are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product. sees a pop-up. Try to keep your operations simple. Long API APIs (application programming interfaces) are a set of protocols and definitions developers use to build and integrate application software. APIs act as the connective tissue between products and services. (application programming interface) calls, for example, might not complete before the page closes.

When you build applications in a workflow, all modules load and work on an existing submission ID after the first  Task node. Because your Employee Travel Request workflow application loads with a submission ID, the initRuleEmailValidation Radio Button component icon Initializer uses the Edit Submission Trigger Type.

The Initializer's Outputs Enter outputs components and actions you want the component to perform. table tells the Initializer what to trigger once it fires. In this module, the initRuleEmailValidation Radio Button component icon Initializer triggers the ruleEmailValidation Decisions Component icon Decisions component. So, the Property ID A Property ID is the unique field ID used by Unqork to track and link components in your module. column of the Outputs table is set to ruleEmailValidation with the Type set to trigger and the value to GO.

Image showing the initRuleEmailValidation Initializer component's Outputs table configuration.

Decisions Component Configuration

The next component in your Email Validation module is the ruleEmailValidation Decisions Component icon Decisions component. This component is what validates the end-user End-Users are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product.'s employee email address to confirm it matches the @unqork.com domain.

As you just read, the initRuleEmailValidation Radio Button component icon Initializer triggers this Decisions component. Because another component triggers the ruleEmailValidation Decisions Component icon Decisions component, the Trigger Type is set to  Manual.

The Inputs table is how your Decisions component references the input. The Decisions component validates the employee's email address, so the Property ID column of the Inputs table is that of the employeeEmail  Email component. The Type is set to contains because the Decisions component checks if the employeeEmail value contains the @unqork.com domain.

Image showing the Inputs table configuration of the ruleEmailValidation Decisions component.

The Decisions component's Outputs table has two outputs: employeeEmailValidation and requestStatus. These Property IDs both have the Type set to value. This means both properties have an output value based on the Decisions component's Micro Decisions table.

Image showing the Outputs table configuration of the ruleEmailValidation Decisions component.

The Micro Decisions table is the validation configuration of the Decisions component's logic. Here, the Input and Output values are decided, and the action taken depends on whether the validation fails or succeeds.

For example, if you open the ruleEmailValidation Decisions Component icon Decisions component's Micro Decisions table, you can see the Input Values, Output Values, and action columns.

Looking at the first row, if the employeeEmail  Email component contains the Input Value of @unqork.com, then the employeeEmailValidation Hidden component is set to Valid, and the requestStatus_value action is unchanged. In the second row, you can see that if employeeEmail doesn't contain @unqork.com, then employeeEmailValidation is set to Invalid. For Invalid output values, requestStatus_value is set to Rejected.

Image showing the Micro Decisions table configuration of the ruleEmailValidation Decisions component.

Like other logic components, the Decisions component contains a Unit Testing tool for testing configuration. Here, you can test different inputs and see how the output functions. You can try this yourself by selecting Create Test. In the Value column, enter an email address that doesn't match the company @unqork.com domain. Below, you can see an example of an @gmail.com domain value. When you click Run Test, the Output table shows that employeeEmailValidation is Invalid and that requestStatus is Rejected. These results from the Unit Test show that the validation works as expected.

Image showing the Decisions component's Unit Testing tool. The image displays an invalid, rejected test from an @gmail.com domain.

You can also test a valid response in the same way. In the Value column, enter an email address that matches the company @unqork.com. If the employeeEmailValidation returns a Valid response in the Output table, your Decisions component is ready to go.

Image showing the Decisions component's Unit Testing tool. The image displays a valid test from an @unqork.com domain.

Hidden Component Configuration

The last component in the Email Validation module is the employeeEmailValidation Hidden component. This component holds the output value (Valid or Invalid) from the ruleEmailValidation Decisions Component icon Decisions component. You'll reference this Hidden component in your workflow to determine which pathway the end-user End-Users are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product. takes in your application.

Exclusive Gateway Node Configuration

Once the end-user End-Users are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product.'s email address domain is validated, the next step is to direct the workflow path based on their validation response. For this use case, you'll direct the end-user End-Users are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product. to one path if their email address is Valid or another if their email address is Invalid.

To split your workflow path into two different paths based on the validation response, you'll use the Exclusive Gateway node.

1. Open your Creator Workshop App workflow application.
2. Drag and drop an Exclusive Gateway node into the Automated swimlane.
3. Select the Exclusive Gateway node to open its Settings Menu.
4. Click  Edit to open the Edit Exclusive Gateway menu.
5. In the Label field, enter Email Validation Gateway.
6. Disconnect the Email Validation  Task  node from the End node by clicking on the arrow connection and pressing Delete (Return) on your keyboard.
7. Connect the output port (right) of the Email Validation  Task node to the input port (left) of the Email Validation Gateway  Exclusive Gateway node.
8. Save... your workflow.
9. In the Save to Version History window, select Save.

Configure the Valid Workflow Path

Valid Email Configuration

If the end-user End-Users are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product.'s validation returns Valid, your application will divert them to another module. This module will eventually prompt them for more information about their travel request. For this use case, you only need to create the Task node and module.

1. Open your Creator Workshop App workflow.
2. Drag and drop a  Task node into the Employee swimlane.
3. Select the  Task node to open its Settings Menu.
4. Click  Edit to open the Edit User Task menu.
5. In the Label field, enter Employee Travel Information.
6. Under Module, select Create New Module. The Module Title and Module Path populate with default values.
7. Click Create.
8. Select the End node to open its Settings Menu.
9. Click  Edit to open the Edit End Event menu.
10. In the Label field, enter Employee Submitted.
11. Connect the output port (right) of the Email Validation Gateway  Exclusive Gateway node to the input port (left) of the Employee Travel Information  Task node.
12. Connect the output port (right) of the Employee Travel Information  Task node to the input port (left) of the Employee Submitted End node.

Image displaying the Creator Workshop workflow application with an Exclusive Gateway node in the Automated swimlane leading to a Task node in the Employee swimlane. End-users will take this path if they enter in a valid @unqork.com email address domain.

Valid Email Path Configuration

For the pathway to work, you must configure the Email Validation Gateway Exclusive Gateway node's path to the Employee Travel Information  Task node.

To edit the path: 

1. Select the Email Validation Gateway Exclusive Gateway node.
2. Select the Exclusive Gateway node to open its Settings Menu.
3. Click  Edit to open the Edit Exclusive Gateway menu.
4. In the Output Links section, you can see the No Label link between the Email Validation Gateway Exclusive Gateway node and the Employee Travel Information  Task node.
5. In the No Label link, select Edit to open the Edit Exclusive Gateway Link menu.

Image displaying the Output Links setting in the Edit Exclusive Gateway menu. The image shows the No Label path between the Exclusive Gateway node and the Employee Travel Information Task node.

6. In the Label field, enter Valid Email Path.
7. In the Logic field, enter employeeEmailValidation="Valid". This syntax tells the Email Validation Gateway Exclusive Gateway node to continue down this path if the employeeEmailValidation Hidden component's value is "Valid".

Image showing the Edit Exclusive Gateway settings menu. The Label field displays the Valid Email Path. The Logic field displays the Valid response criteria from the employeeEmailValidation Hidden component.

 

8. Save... your workflow.
9. In the Save to Version History window, select Save.

Configure the Invalid Workflow Path

Invalid Email Configuration

Next, let's configure another pathway if the validation response is Invalid. This path uses a Message node to email the applicant, notifying them that their email address didn't meet the domain requirement.

1. Open your Creator Workshop App workflow.
2. Drag and drop a Message node into the Automated swimlane.
3. Click (Expand) to expand the node settings menu.
4. Select Edit Message Event menu.
5. In the following fields, enter or select these values:

Field

Value

Label

Invalid Email Address

Send via

Email

To

{{data.employeeEmail}}

From Name

Employee Travel Requests

Reply To

no-reply@unqork.io

Subject

Travel Request Rejection

Template

Copy 
Hello {{data.employeeFirstName}} {{data.employeeLastName}},<br>
<br>
Unfortunately, your application could not be completed and submitted for consideration because the email address that you entered ({{data.employeeEmail}}) did not match our expected email domain restriction.<br>
<br>
We encourage you to apply again in the future but cannot accept your application at this time.<br>
<br>
Signed,<br>
<br>
The Employee Travel Processing Team

This tells the Message node to pull the end-user's information from the Employee Travel Information module and populate the email correspondence.

Image displaying the Message node configuration that notifies invalid email address domains that their travel request application has been denied.

6. Drag and drop an End node into the Automated swimlane.
7. Select the End to open its Settings Menu.
8. Click  Edit to open the Edit End Event menu.
9. In the Label field, enter Invalid Email Path End.
10. Connect the output port (right) of the Email Validation Gateway Exclusive Gateway node to the input port (left) of the Invalid Email Address Message node input port.
11. Connect the output port (right) of the Invalid Email Address  Message node to the input port (left) of the Invalid Email Path End End node.

Invalid Email Path Configuration

As you did with the Valid path, the Invalid path must also be configured to divert the end-users End-Users are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product. who did't submit an email address with the @unqork.com domain.

To edit the path: 

1. Select the Email Validation Gateway Exclusive Gateway node.
2. Click Edit to open the Edit Exclusive Gateway menu.
3. In the Output Links section, you can see the No Label link between the Email Validation Gateway Exclusive Gateway node and the Invalid Email Address  Message node.
4. In the No Label link, select Edit to open the Edit Exclusive Gateway Link menu.
5. In the Label field, enter Invalid Email Path.
6. In the Logic field, enter employeeEmailValidation="Invalid".
7. Save... your workflow.
8. In the Save to Version History window, select Save.

Here's what your workflow looks like once complete: 

Image displaying the completed Creator Workshop workflow application use case.

Now that you've completed this workflow use case, view and test it in Express View Express View is how your end-user views you application. Express View also lets you preview your applications to test your configuration and view the styling. After configuring a module, click Preview in the Module Editor to interact with the module in Express View. Go through the steps using a valid email address. Then, use a functional invalid email address and see if you receive an email from the Invalid Email Address  Message node.

In the next use case, you'll complete the Building Your First App course by configuring the Employee Information module.