Testing your Form

Once your form is finalized meaning no further modifications are needed, you can begin testing your form.

Formal end to end testing by your department is required, as your approval that the form is working as expected is necessary to migrate your form to Production.

Activate your Form 

Activating your form allows you to test filling out the form as a participant would. Accessing your form for testing can be done a couple ways.

First, you must activate your form by going to your Sandbox, under Action drop-down, select Activate Form Template.  Form Name > Action > Activate Form Template

• A red circle labeled ‘No’ will appear next to a form that is Deactivated. 
• A dark grey circle labeled ‘Yes’ will appear next to a form that is Activated. 

1. Fill Out Form - Once your form is activated, you will see an external link icon next to your forms name. Click on this hyperlink to access your form for testing. 
2. Form URL - Once your form is activated, you can use your Form’s URL to access and complete, just as a participant would. There is the option of using your form’s SSO URL (requires CASing in using NetID/Password) or External URL (No CAS in required). See Form URL details and differences under Designer Resources >  Form URLs.

Modifications for Testing Purposes 

In order to properly test your multi-participant form from end to end, there are several modifications that will make testing easier. You must remember to change these setting back prior to migrating to production. 

• Allow Repeat Signatures - On all co-signer Participants, enable Repeat Signatures which will allow you to act as all participants of the form. i.e. The Owner and each of the co-signers. 
• Hard-code Co-signers - If a co-signer’s email address is hard-coded, ensure you modify the email address to your email address so you don’t sent emails to the actual forms co-signer(s), but instead the emails go to you, or the email address designated for testing purposes. 
• Label Emails in Subject Line - For all form related emails, add a label prefix in the Subject Line to identify which email it is. Since you are acting as all participants within the form, it can get confusing when you go to review the emails. Labeling the email’s subject lines allow you to easily identify which email you are receiving and reviewing. Some examples:
  • Owner Confirmation Email Subject Line would state “Owner Confirmation Email: <actual subject line text>”
  • Co-signer (Advisor)  Subject Line would state “Advisor Co-signer Notification: <actual subject line text>”
  • Owner Notification Subject Line would state “After Advisor submits, Owner Notification Email: <actual subject line text>”

Testing Guidelines

When testing your form, there are several areas that should be validated to ensure compliance and consistency across Yale University. 

Testing is required before any form can be published. The goal is to ensure the form is accurate, functions correctly, routes properly, and displays the right information to the right people.

These guidelines apply to all forms, regardless of complexity, and include standard testing, impersonation testing, and API validation where applicable.

Here are guidelines you should validate when testing your form:

• Form Items & Field Behavior
  • Visibility rules show/hide the correct fields for each participant
  • Required fields block submission when empty
  • Field formats validate (dates, emails, numeric formats)
  • Dropdowns have correct options, order, and spelling
  • E-signature appears only for the correct participant
• Layout, Spacing & Content
  • Clean spacing between questions and sections
  • Consistent font family, size, and formatting
  • Titles, section labels, and logos are correct
  • Instructions are clear and error-free
  • Line breaks and paragraph spacing look clean
• Workflow, Routing, & Rules
  • Each participant receives the form at the correct step
  • Routing rules trigger correctly in all scenarios
  • Branching logic functions (Approve/Return/Deny/etc.)
  • Hard stops fire exactly when required
  • No skipped steps or looping
• Emails & Notifications
  • Correct recipients at each step
  • Subject lines meet standards
  • Dynamic values populate with accurate data
  • IF/ENDIF conditional text appears correctly
  • All links function properly
  • Logo, spacing, and formatting look clean
• Confirmation Page
  • Message is correct and approved
  • Department logo and formatting look clean
  • Links or next steps function properly
• Impersonation & API Testing (if Applicable)
  • Impersonation Testing:
    • Test multiple user types (i.e., different student types) to confirm how their data changes visibility, routing, and responses
    • The participant sees only the fields intended for their role
    • Required fields and hard stops work properly 
    • Routing sends the form to the correct next participant
    • Emails they should receive actually send
    • Confirmation page is correct for that step
    • Prefilled fields appear correctly for that user
  • API Validation
    • Prefill values match source system data
    • Mapping is correct for all scenarios
    • Fields are NOT editable
    • API calls fire at the correct workflow step
    • No duplicate, early, or missing API calls
• Edge Case Testing
  • Changing earlier answers updates visibility and routing correctly
  • All routing paths function correctly
  • Participants with incomplete records (e.g., missing codes, missing address fields) do not cause system or rule errors
  • Optional fields can be left blank without disrupting logic, routing, or data validation

• Department Sign-Off

  After all testing is complete, the department submits their sign-off.
  If DFE setup or additional technical configurations are needed, those occur after sign-off.