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.

Flowchart of a process with several labeled steps, including "Set Field," "Copy Fields," and "Notify." "Notify" is highlighted with a red oval.

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

Edit Notifications window for GoAnywhere approval. Contains a table with columns for attention level, role, and person. Email section with subject and body fields.

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.

Flowchart section showing decision node with "Processhiddenaffiliation = 'student'," leading to "Cancel Submission" and then "Show Message."

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

Code snippet with highlighted section includes logic to process hidden affiliations. It checks if "hiddenAffiliation" equals "student" and is not 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.

Code snippet showing a text assignment, with "txtRouteTo" and "txtSubmitterEmail" variables, and highlighted equals sign. Simple programming concept. Flowchart with decision node labeled "txtRouteTo=" with T and F paths. T leads to "Show Message: Sorry! The forms cannot." F leads to "Connect: ldap.oakland.edu."

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.

User interface panel showing connection settings and parameters. Connection set to 'ldap.oakland.edu', with email input for sending data. Return parameters include primary affiliation, affiliation, full name, last name, and department.

A beige rectangular button with the word "Approve" in bold, black text, conveying a sense of acceptance and confirmation.

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.

Flowchart showing a decision process with nodes connected by arrows. Some nodes and paths are marked with red "F" and green "T" symbols, indicating true/false logic.

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.

A text window shows "txtUTS" with plus and 1 signs. On the right, a selection panel offers options for value types, with "Field" selected.

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

Flowchart depicting data process: A decision node with "T" and "F" branches for setting table rows and copying fields to DBTEST. Emphasizes data management flow.

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

A mapping table with columns "From" and "To" links database fields like "txtpersonsubmit" to "tblSignatures - colName," using dropdown menus. Screenshot showing two text entries labeled "txtpersonsubmit" and "txtCommentsAprp" with adjacent dropdown menus labeled "TBLComments - Text Input Column..." in a software interface.

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

A software interface shows database connection settings with fields for DBTEST and action options. A table lists data fields with names and sources.

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.

Flowchart diagram showing progression from "Show Page: Signatures" to "Show Message: The form has been," leading to "Submit Data: Close Browser Window."

A beige button with the word "Forward" in black text, conveying a sense of movement or progression. The design is simple and functional.

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.

Flowchart depicting a decision-making process with three main components: "Set Field," "Connect," and "Show Message." Arrows indicate logical paths.

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
Tue 10/14/25 4:01 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.

Related Services / Offerings

Related Services / Offerings (1)

Report issues or Request services with Data Warehouse and ETL.