PerfectForms: Button Behaviors

Summary

An explanation of button behaviors in PerfectForms

Body

Who is Eligible?

Active faculty and staff who are eligible for PerfectForms.

Overview

All forms have buttons that allow submission and routing of the form. Behind each button is behavior that helps with the manipulation of the form. Each button behavior also transfers signature information into the signature table and sends notifications as needed.

Forms submitted to UTS create tickets which are pre-assigned to a user or team.

For forms that create footprints ticket:

The following fields need to be included at the end of the message box of the Notify object for the ticket to be created.

  • Submitter = Email Field (ex. txthiddenEmail)
  • Contact = Email Field (ex. txthiddenEmail)
  • Categories = Department Applications
  • Level 2= File Transfer
  • Type = Task

This can be done both on the Submit button or the Approve button. Depending on the form – a supervisor may be able to fill out a form on behalf of a student/employee and submit it directly to uts or the form can be submitted to the supervisor that will then approve and route the form to uts.

Under the ‘Button is pressed’ behavior – the Notify object when opened shows the notification message to be sent.

Workflow diagram with Notify action highlighted between Set Field and Show Page steps.

The fields for the footprints ticket would be at the end of this message as shown below.

Edit Notifications window showing email notification settings and message content.

Depending on the kind of form created, a form can be initiated by a student. However, a form cannot be routed to a student.

Before submitting a form it, we need to know if, it is submitted by the student or staff. This information is captured from LDAP. Both the primary and secondary affiliations.

The first step in verification is to capture who the form is being routed to. This ‘Oakland Email for routing’ email is used to get information about the person’s affiliation. There are two conditions one, students are not allowed to route the form. Second, on some forms - a submitter is not allowed to route forms to themselves.

The following branch behavior checks if the person who the form is being routed to is not a student. If the person is identified as a student, the submission is canceled and a popup message is displayed.

Workflow showing Cancel Submission step followed by a message stating email cannot be routed.

processhiddnaffiliation is set equal to “student” and hiddenAffiliation is set equal to <empty>

Condition checks whether Process ID affiliation is student and hidden affiliation is empty.

If it is a student, then cancel the submission and show message should be - “The email you have provided cannot be processed. Use the Check Email button to verify the email is associated with a valid OU employee.” Then show other message saying “This Route to email you have provided may be a student account. This form does not allow for routing to students.”

The following branch behavior checks to see if the user is routing the form to themselves. If the routing email and submitter email is same then the error is shown if it is different than it moves to the next step. Use the Simple branch, In the properties go to the Advanced then chose the txtRouteTo equal to txtSubmitterEmail.

Condition compares txtRouteTo and txtSubmitterEmail values for equality. 

Workflow routes matching email values to a Connect step; otherwise displays an error message.

Show message should have “Sorry! The forms cannot be routed to yourself. Please provide a valid Oakland University email address.”If the User is not submitted the form to themselves In the Connect property, a connection will be set to ldap.oakland.edu (7) and Action will be set to GetDirectoryDataFromEmail. In Send Parameters, eMail is set to txtRouteTo. In the Return parameters, PrimaryAffilation, Affiliation, and FullName is set to the following targets relatively. Processhiddenaffilation, hiddenaffilation, hiddenEmailName.

Directory lookup configuration mapping email input to affiliation and name return fields.

Approve button used to accept or authorize a request.

Forms can only be approved by the supervisor or UTS. To make sure the forms are Approved only once to UTS. Following behavior is implemented.

Workflow showing Set Field action and routing logic connected to directory lookup and messages.

Set Field behavior includes the following commands. In the simple branch, the txtUTS field is compared with the uts@oakland.edu email. If the UTS email matches. Then condition becomes true and in the set Field box, txtUTS is incremented with +1. Then it goes to simple branch with checks if the txtUTS is more than one. If it is more than one then it shows the error message. “You cannot route this form more than once to UTS.” if it is less than or equal to one then behavior moves to connect.

Set Field configuration adding 1 to the txtUTS field value.

The next step is now to copy all the fields to the signature table – this happens for all the buttons.

Workflow with table row updates, field copying, and database connection actions.

Following fields are copied. 8 field are copied if the user has input comments that need to be transferred to the signature table.

Field mapping table linking form fields to signature table columns. 

Field mappings send submitter and approval comments to comment table columns.

Forms also can be viewed in the user's INBOX. The INBOX can be accessed from the forms menu (https://forms.oakland.edu) tab EForms Inbox. The following shows what an approval connection may look like.

DBTEST Connections

Database update configuration mapping form fields to status, stage, and timestamp values.

Once the DBTest Connections is made. All the other hidden fields should be cleared. Then copy fields can be used to copy the comments to hidden Comments and then clear the txtcomments.

Before doing a Submit Data. Show message box should be added, because if it is not added the signature page will be cleared on the submission.

Workflow displays confirmation message, then submits data and closes the browser window.

Forward button used to send a request to the next step in a workflow.

Everything will remain same except changes in the notification message. The {field name} form was forwarded to you. Additionally. If required that form cannot be forwarded more than once to uts. Then the following behavior can be added.

Workflow routes email lookup through directory connection with validation and field updates.

Here first with simple branch it is checked that uts@oakland.edu = txtroute - if it does then set field is used increment the field number. In the next simple branch, it is compared with the txtUTS. To check If txtUTS is greater the 1 or not. If it is more than once then we can show the message “You cannot route this form more than once to UTS.” If it is less than 1, then use the connect to move forward to other behaviors.

Text interface with a highlighted word "txtUTS" and symbols beneath, including a plus sign and the number 1, conveying a numeric input or setting context.

An oval button with a beige gradient background labeled 'Disapprove' in bold black text, conveying a sense of rejection or disagreement.

Similar to approve button. Just change is the notification message. The {field name="txtemailnotification”} form has been disapproved.

A rounded rectangle button with a green check mark on the left and "LOCK" in bold red text on the right against a beige background, indicating a locked status.

Add set Field Where cbLock is set to ‘checked’. Also, Add copy Fields where following fields are copied.

Flowchart depicting three steps: "Set Field" labeled cbLock, "Copy Fields" with two fields, and another "Set Field" labeled txtCommentsAprp. Arrows indicate sequence.

A table displaying two columns labeled 'From' and 'To,' with text entries like 'txthiddenEmail' and 'txtpersonwholocked' alongside buttons.

A gray button labeled "Unlock" with black text on a minimalistic, light background. The button conveys a subtle, modern design.

In the unlock button, a simple branch will be needed to find if txthiddenuserId = txtpersonwholocked. If it is not a same then show the Message “Sorry, you cannot unlock the form since you don't have privileges”, clear the txtpersonwholocked, and set cbLock to checked.

Flowchart depicting a conditional path. "Show Message" box with text, "Sorry, you cannot unlock," leads to "Set Field" boxes labeled "txtpersonwholocked" and "cbLock."

Additional Support

  • OU Technology Center
  • 44 Oakland Center
  • Rochester, MI 48309-4479
  • (248) 370-4357
  • Office Hours: M-F 8:00am - 5:00pm

Details

Details

Article ID: 71
Created
Tue 3/25/25 1:26 PM
Modified
Fri 9/11/26 4:56 PM

Related Articles

Related Articles (4)

A guide to prepare your inbox in PerfectForms.
An explanation of form elements in PerfectForms.
A guide on installing forms into production in PerfectForms.
A guide to moving new versions of a form to production in PerfectForms.