There are three icons in Test mode that you can use to see what your form will look like and how it will work on an iPhone or an iPad. Theses icons appear at the top of the screen - desktop, tablet and smart phone. The default view is desktop.
Clicking on the the tablet and smart phone icons gives you an approximate view of the form on the tablet or phone. You can enter data in the Phone and Tablet views just like you can in the Desktop view to test your form. This is very helpful when designing forms for mobile devices.
Tablet and Phone views are not precise and there may be slight differences when rendered on the actual device. It is highly recommended that you test the form on the actual device to be certain.
Before you share your new form or flow with users you'll want to test it to make sure it looks and works the way you want. You will want to test that the form is properly validating data entered into each control, that all your rules are correctly causing the behaviors such as show/hide and calculations that you want.
Each time you supply a value in a control, sends an asynchronous request to the server to validate the data. This means users will get immediate feedback while they are using your form. They do not have to wait until they click the form's submit button for example to discover that a zip code is missing a digit or that they neglected to fill in a required phone number field. Try to type letters in a number control, for example, and you’ll immediately see an error message.You'll want to test your form to make sure that you are using the correct control based on the validation you want. For example if you used a Text control for a phone number field, you'll won't see the correct error occur if you enter an incorrect phone number. Go back and edit your form to change the control type for that field from Text to Phone.
Your form's submit button will be disabled until valid data is entered into all required fields and if data is entered into an optional field that data also must be valid. You will want to test your form to verify that all the fields that you want to require the user to fill are indeed set to required in the form. If the user does not enter data into all your form's required fields the submit button will remain greyed out until they do. This prevents the user from submitting a form that does not yet have all the data that you require. The submit button will also disabled if you enter invalid data into an optional field. For example enter abcde into a Money control. An error will appear to alert the user that the entered data is invalid. And even if all required form fields are filled you'll see that the submit button is again greyed out until the error is corrected. For example, replace abcde with 89.25 and the submit button can be clicked.
Sometimes you'll test your form and see that the submit button remain grey'd out even when all required fields appear to be filled with valid data. The cause is always a hidden required field with no data or a hidden field with invalid data. Since the field is hidden your users won't be able to enter a value into that required field nor to correct an invalid value in that field and will therefore never be able to submit your form. In a simple form it won't be hard for you to open it in the form designer, find the hidden required field and fix the problem. In a large form or one that has dynamic business logic that makes fields hidden/visible or required/optional or sets values in business rules, you'll need to debug this problem while testing the form.
The first step to solving this issue is to understand which control(s) are causing this issue. The Firebug tool, http://getfirebug.com in the Firefox browser is a great way to find hidden controls which are invalid or required and causing the submit button to remain disabled. Test your form and enable the firebug tool. Open firebug's HTML tab and search for all instances of s-invalid using the search box in the tool's top-right corner. This will take you to the HTML of each control in the invalid state. The control's name can be found in that HTML. Now you can edit your form in the designer, find that control and fix the issue.
Note that if a required control is inside a hidden section, then that section will also be invalid and you will also see s-invalid in the section control's HTML. This s-invalid is not the root cause of your bug. You will have to continue searching with firebug further to get to the actual control inside the section control that is the root cause.
Test your form to verify that all your business rules are working as expected. For instance if you have a radio field "Billing address same as Shipping?" and select "no", you would expect the hidden Shipping Address section to become visible and required. Test each form field that has dynamic business rules to verify that they are working as you want. Also remember to test the negative cases, for example if you then click "yes" to the billing address question, make sure the Shipping Address section control becomes hidden and optional again. Note it's very important that hidden controls are not required as discussed above.
When you are done testing and are ready to roll out your form, mark it public or public in tenant via the icon and make it available by sharing it.
Forms can be translated to multiple languages using the internationalization feature which enables you to easily localize your forms for target audiences that vary in culture, region and language. supports localization from the browser's locale setting.
You can test the translation files you create and upload into by clicking the test icon on the Internationalization screen or you can use the &locale URL parameter to initialize the form with other languages. See Multi Language Support for details on creating translations and testing locale translations .