Workflow Designer

This feature is designed for the developer who wants to customize maintenance applications with a variety of programmatic elements, such as conditional actions, API invoking, easier error message implementation, or even better server-side error checking. Often times, the solution for these needs was to write external objects. However, the feedback we continually received from our customers was that they want to work in m-Power as much as possible, and not need to resort to writing external objects outside of m-Power. With that feedback in mind, we implemented the Workflow Designer. The designer gives you a graphical interface to load a variety of actions or conditions to control the behavior of the program once submit is clicked.

Video Walkthrough

Getting Started

Clicking the “Application Workflow” button on the Build and Customize screen of a maintainer will open the Workflow Designer screen. Clicking the “Add actions” button will open a dialog to choose the desired action. All action and condition windows offer a tooltip helper when hovering over the form label.

Setting a Condition

After setting a condition, choose the action to follow if the criteria is true or false. If the maintainer should submit as normal, leave the appropriate condition result with no action.

Compare a Field Value

Name: Name the conditional check.
Field: Select a field from your current maintainer, the username, or a field from a previous step’s data lookup.
Relation: Operator to compare the value.
Value: You may hardcode a value, select a field from the current maintainer, the username, or a field from a previous step’s data lookup.
Use Case: Can be used to make sure a field is greater than another field. Such as an ship date must always be after an order date. Hardcode the comparison value where if a feedback field is equal to ‘NEGATIVE’ to initiate a follow up email. If used after a lookup data action, pass a value to the data lookup to confirm a product number exists in your products table before an order can be placed. Countless other use cases are at your disposal.

Validate an Email Address

Name: Name the conditional check.
Field: Select the email field from your current maintainer.
Relation: Is a valid email address.
Validation: Requires an ‘@’ symbol, at least 1 character before and after the ‘@’ symbol, and a ‘.’ after the ‘@’ symbol.
Use Case: Can be used to make sure an input contains a valid email address upon form submission. Include a “Return an Error Message” action if this condition result is FALSE.

Validate a Social Security Number

Name: Name the conditional check.
Field: Select the Social Security Number field.
Relation: Is a valid SSN.
Validation: Requires 9 digits (i.e. 999999999) or 9 digits with appropriate dashes (i.e. 999-99-9999).
Use Case: Can be used to make sure an input contains a valid Social Security Number upon form submission. Include a “Return an Error Message” action if this condition result is FALSE.

Validate a Password

Name: Name the conditional check.
Field: Select the password field from your current maintainer.
Relation: Is a valid password type.
# Special Chars: The number of required special characters in the password.
# Upper Case: The number of upper case letters required.
Min Password Length: The minimum number of characters allowed for the password.
Special Chars Allowed: The characters considered/allowed as special characters in the password.
Use Case: Can be used to customize user password criteria if using a maintainer for users to control their own passwords. Include a “Return an Error Message” action if this condition result is FALSE.

Check if a Field Has Changed

Name: Name the conditional check.
Field: Select the field from the current maintainer to check if the value has changed (add/update).
Use Case: Perform an action if a field has changed. For example, if the order shipping date has changed, send an email to the account manager and the client.

Check the action mode

Name: Name the conditional check.
Action Mode: Select the action mode to trigger the next step.
Use Case: Perform an action based off the action mode. If an order is added, send a confirmation email and write the order record to a sales table. If an order is updated AND the status has changed to ‘SHIPPED’, send an email to the customer.

Check the user’s role

Prerequisites: Security enabled, Roles previously created.
Name: Name the conditional check.
Relation: Either ‘Equal To’ or ‘Not equal’
Role: List of roles created from the ‘Manage Runtime Roles’ in the ‘Users, Menu & Security’ screen.
Use Case: Can be helpful for role based validation. For example, make sure only certain roles are able to delete records.

Compare a date field to a calculated date value

Prerequisites: Must be used with a true date field.
Name: Name the conditional check.
Field: Select a true date field from the current maintainer or from a date field from a previous step’s data lookup.
Relation: Operator to compare the date.
+/-: Add or subtract from the current date.
#: Number of units to add or subtract from.
Date Measure: Select days, months, or years to calculate.
Use Case: If an order needs 7 days minimum processing time, if the ship date is within 7 days of the current date, return an error message.

Lookup returns at least one record

Prerequisites: Lookup Data step must proceed this condition.
Name: Name the conditional check.
Condition: Specifies that records have been found from the data lookup step.
Use Case: After passing a customer number to a data lookup over the customers table, if at least one customer record is found, perform another conditional check to make sure said customer is not in an accounting hold status.

Lookup returns no records

Prerequisites: Lookup Data step must proceed this condition.
Name: Name the conditional check.
Condition: Specifies that records have not been found from the data lookup step.
Use Case: After passing a customer number to a data lookup over the customers table, if no records are returned, call an error message action for that customer not existing.

Triggering an Action

Select the action to execute when the form is submitted.

Lookup Data via Retrieval

Useful when needing to pass a form value to a retrieval for finding form specific data.

Prerequisites: Previously created retrieval.
Name: Name the Lookup action.
Retrieval: Select the appropriate retrieval from the current dictionary.
Additional URL Parameters: (Optional) Passing parameters to the retrieval can help filter the data so only the desired records are returned.
Map Available Fields To Lookup List:Select the fields to map from selected retrieval to the current maintainer. Additionally, you may select the username or a field from a previous step’s data lookup. Map additional fields as necessary.
Use Case: Pass the form’s customer number to a customer master retrieval to make sure the customer is a current customer.

Return an Error Message

Useful for several conditional checks such as field/form validation, action mode validation, role based validation, etc. This is a server side validation check via java prior to writing to the database.

Prerequisites: Setting a condition.
Name: Name the error action.
Error Message: The text that will be displayed as the error message.
Apply Error to specific field:(Optional, Bootstrap only) If a field is selected, the error message will appear below the specified field. If not selected, a general error message will appear above the form.
Use Case: Return a custom error message if a custom field condition is not met, if records are not returned from a data lookup step, or if a user’s role is not permitted a certain action.

Call a Task Group

Prerequisites: Previously created task group in the Messaging and Scheduled Task utility.
Name: Name the action.
Task Group: Select the appropriate task group
Map Fields to Task Group: (Optional) Passes form values from the maintainer to the task group. Map additional fields as necessary. Note that fields/calculations from a proceeding ‘Lookup Data with a Retrieval’ action can be passed as parameters to the task group as well.
Use Case: Call a task group to trigger a report be emailed passing through the customer number to filter the emailed report.

Set a Field Value

Name: Name the action.
Field to Set: Select the appropriate field to set a value.
Value: Hard code a value or select a field to copy from. You may select a field from the current maintainer, the username, or a field from a previous data lookup step.
Event: Specify when the field value will be set, which is either when the maintainer form is loaded or when the maintainer form is submitted.
Use Case: If in add mode, set an order status to ‘PLACED’ to begin processing.

Send an Email

Prerequisites: Email server set up through Messaging and Scheduled Task Utility message configuration.
Name: Name the action.
To: Specify the recipient. You can hard code an email address and/or select a field that contains the email address from the drop down. Separate multiple addresses/fields with commas.
CC: (Optional) Specify the optional CC recipient. You can hard code an email address and/or select a field that contains the email address from the drop down. Separate multiple addresses/fields with commas.
Address List: (Optional) Select a distribution address list. A single email will be sent to all the email addresses produced by the list.
Map Fields to Address List: (Optional) Pass values from the form to filter the list of address list recipients. Only available after selecting an address list.
Subject: The subject of the email. You can substitute field values into the subject using the drop down button on the right side of the input
Email Message: Serves as the body of the email. Include fields from the maintainer or from previous step’s data lookup. Type [[ to see a list of available fields to include in the email.
Use Case: Send a text only email to an account manager an salesman after an order is placed.

Note: Emails sent through this method are interactive. The users’ browser will pause until all emails are sent. If there are many emails to be sent, consider using a task group instead which will send them in batch while the user continues to work.

Send an SMS text message

Prerequisites: SMS connection info set up through Messaging and Scheduled Task Utility message configuration.
Name: Name the action.
To: Specify the mobile recipient. You can hard code a mobile number and/or select a field that contains the mobile number from the drop down. Separate multiple numbers/fields with commas.
Address List: (Optional) Select a distribution address list. A single message will be sent to all phone numbers produced by the list.
Map Fields to Address List: (Optional) Pass values from the form to filter the list of address list recipients. Only available after selecting an address list.
SMS Message: Serves as the body of the SMS message. Include fields from the maintainer or from previous step’s data lookup. Type [[ to see a list of available fields to include in the message.
Use Case: Send an SMS text message to a customer notifying them once an order status has been sent to ‘SHIPPED’.

Redirect to Another Page

Name: Name the action.
Application Type: Select the application type to redirect to.
Select Application: Select the application for the redirect.
URL: This will be auto-populated if selecting an application. Additionally, you may hardcode any URL you wish to redirect.
Map Fields: Select fields from the maintainer form or previous lookup step to the redirect application.
Use Case: Redirect the user to a confirmation retrieval after submitting a new record.

Write Record via Maintainer

Calls another maintainer to write to a table in one step mode.

Name: Name the action.
Select Maintainer: Select the maintainer that will write to the database.
Action Mode: Specify whether to add, update, delete, or copy data on the database.
Additional URL Parameters: Pass additional parameters to the maintainer when called.
Map Fields: Select fields from the maintainer form or previous lookup step to the called maintainer.
Use Case: If a record is added to one table and must be added to certain subsequent tables, use this action to write the records to the other tables using different maintainers.

Call a Third Party API

Name: Name the action.
Type of API: Choose either POST or GET API methods.
API URL: The URL to call the API.
API Headers Specify a comma separated list of any required API Headers (HeaderName:HeaderValue). Type [ to pick from a list of fields to include in the headers.
API Message Body Format: Specify a custom API body or use m-Power’s default JSON format. The m-Power default json format is : {field: value, field2:value2,..}
API Message Body: Only available if using custom body format. The API body to POST. Type [ to pick from a list of fields to include in the body.
Use Case: Post a new order record to a third party billing service.

Copy/Connect to Existing Action

Copying a Step

Selecting this option allows the developer the ability to duplicate/copy an action or condition and branch off from the step of origin. This prevents the need to manually recreate steps.

Connecting a Step

Selecting this option allows the developer the ability to connect steps together. This is helpful when wanting to perform the same action after different conditions. You may remove a connection by clicking the red ‘X’ on the connection line.

Inserting/Removing Steps

You may insert a step inbetween existing steps by clicking the green ‘+’ on the connection line. You may also remove a connection between steps by clicking the red ‘X’.

Other Notes

• Promoting to production: Promoting a maintainer via the Promotion Utility will automatically promote the workflow/status file. Otherwise, this file is generated in mrcjava/WEB-INF/classes/[DICTIONARY] as MXXXXXs.json. Replace MXXXXX with the maintainer application number.
• Browser Support: All modern browsers are supported. Internet Explorer does not support the workflow designer in the development interface. However, runtime capabilities are supported. For example, a developer can create a workflow design in Chrome and a user can execute said maintainer with workflow in Internet Explorer.
• User Role Support: Only menu version 3+ can support using user roles. Please follow this tech blog to upgrade your menu if needed.