When creating a Unity Form in a test system, use Workflow export and import to export the form out of the test system and bring the form into the production system.
When configuring the auto-name of the Document Type associated with a Unity Form in the Configuration module, it is recommended to include the name of the form in the auto-name string to easily identify what form is associated with the Document Type.
It is recommended that only one form is associated with a Document Type. Multiple forms should be associated with a single Document Type when specific criteria are met. These instances are outlined in Configuring Document Types for Similar Forms.
Always test drive a Unity Form before publishing it. By test driving, you can ensure the form works the way you intended it to before making it available to users.
When using a keyword configured to use a data set, it is recommended to have the form pull the data set values from OnBase, rather than creating a Unity Forms data set.
It is recommended to rename control IDs to unique and intuitive names, especially when using these controls in Custom Actions or the Copy Property to/from Unity Form Field or Copy Property to/from Unity Form Field Workflow actions.
Forms should be built in such a way to serve a specific purpose. Adding too much functionality onto a Unity Form can potentially cause performance issues.
Do not build business logic into Unity Forms if possible.
Fields pre-populated using an integration cannot be modified. If a pre-populated field from an integration is modified, the form cannot be submitted. As a best practice, it is recommended to configure these fields as read-only.
Using C# to generate the hash is more secure when compared to JavaScript when configuring hashes used with shared form integrations.
It is recommended to use an encrypted connection when configuring a shared form URL with an integration.