# Configuring Form Generation Vault can generate and populate any XFA PDF form, for example, FDA Form 2301 or Form 2253. To use this feature, Admins can contact Veeva Support for assistance setting up the _XML Element_ object records and loading the relevant forms into your Vault. Once the structure is set up, Admins configure _Generate Form_ document lifecycle state user actions. When a user triggers a _Generate Form_ action, Vault creates a copy of the template document, constructs the XML from the object records, populates the XFA PDF form using data from the mapped fields, and makes that form the source file for a new document.
## Setting Up Form Types To set up new forms, contact Veeva Support for guidance. In some cases, including 2253, they can provide CSV files that you upload through Vault Loader to create the necessary object records. Note that the provided CSV files work only if all non-standard fields in your Vault use the `__c` suffix, rather than `__vs`. When contacting Support, let them know if your Vault has any `__vs` fields. 1. Optional: Set up the document type to use for the form. If you use a document type that already exists, this is not necessary. 2. Create a new document and upload the XFA form as the source file. This will serve as a template for generating forms. Make sure that the _Document Name_ is something easily understandable because Vault will use it for the generated forms. 3. Create new records in the _XML Element_ object that reflect the structure of the XFA form. We recommend that you work with Veeva Support for this portion of the process. 4. Make any necessary changes to the [form field mappings][1]. You must use the public keys (`Document.product__v.name__v`, etc.), which are easier to find and input than the private keys used in the previous mapping method. 5. Set up [new user actions](/en/lr/12339/) for any document lifecycle states where users will need to generate forms. Note that the _Create Compliance Package_ bulk action runs every _Generate Form_ action on the _Start_ state of the Compliance Package's document lifecycle. ## Form Field Mapping {#mapping} Within the _XML Element_ object, one of the _XML Element Types_ (object type) is _Input_. Vault stores the mapping information for the form in this element type. ### How to Edit Mapping To edit mapping for a form: 1. Navigate to the **XML Element** object record page. You may need to set up a custom tab or change the object settings to show this in **Business Admin > Objects**. 2. Use the filters to show only object records with _Input_ as the _XML Element Type_. Set a filter to only show _Input_ records for the _Form Type_ you're working on. If you plan to add a new XFA forms in the future, we recommend adding a value to the _Form Type_ picklist so that you can easily organize your object records. 3. Each _Input_ record corresponds to a single field input on the form. Some fields (like Yes/No fields) have two or more inputs, one for each option. Edit the **[Formula][2]** for the object records, which should include a mapping to the document, binder, or referenced object field that Vault uses to populate the form field. ### Using the Hierarchy Viewer The Hierarchy Viewer displays a hierarchy of related _XML Element_ object records, for example, an _FDA Form 2253_ object record and its child elements. To open the Hierarchy Viewer, click the **View Tree Layout** button on an _XML Element_'s object record detail page. ### Formulas The _Formula_ field on the _Input_ object record allows you to use Vault's expression language. See [Creating Formulas in Vault.](/en/lr/42857/) ### Field Mapping Syntax Form fields can be mapped to fields on a document, a binder, a document in a binder, a document reference field, or a referenced object field. For each of these, there is a specific syntax you must use, which follows the standard Vault syntax for formulas. If users will trigger the form generation from a binder and you want to use field values from the binder's component documents, you'll use the prefix `DocInBinder`. If you want to use field values from the binder itself or the document from which users will trigger the action, use the prefix `Document`. Examples for document or binder fields: * _Document Name_ for a document in a binder: `DocInBinder.name__v` * _Document Name_ for the binder itself: `Document.name__v` Examples for referenced objects: * _Name_ for referenced product on a binder: `Document.product__v.name__v` * _Internal ID_ for referenced product on a binder: `Document.product__v.internal_id__c` * _Name_ for referenced application (referenced through the binder's product): `Document.product__v.application__v.name__v` In the above examples, you'd use the document field that creates the object reference, then the object field. Example for referenced documents: * _Name_ for the referenced document's field: `Document.product__v.current_pi__c` In the above example, you'd use the object that has a document reference field, then the field on that referenced document. ## Generate Form User Actions Each **Generate Form** action can trigger up to five (5) different forms to generate. ## 2253 Generation Your Vault will not automatically switch over to using this functionality for 2253 generation. You must contact Veeva Support to enable XFA form generation. Once enabled, Vault creates the _XML Element_ records automatically and 2253 generation will function as it did in previous versions. The primary differences are: * You can easily update your field mapping by editing the _Input_ records in Admin. * You can configure the _Generate Form_ user action for any lifecycle state where users need to trigger 2253 generation. If needed, you can make the user action conditional, for example, _Country_ equals _United States_. * The _Generate Form_ user action can generate up to five (5) forms at once, like the older generate action created both the Form 2253 and Supplementary Sheet. * Vault orders documents on the form by Document Number (Material ID), first numerically and then alphabetically. ## Form Generation Errors & Warnings This section can help you troubleshoot common errors that occur with form generation.
Error Explanation
Invalid formula The formula is not valid. This could occur because there is a typo in the function name, the formula uses a nonexistent function, the formula references a nonexistent field, a function uses a field that doesn't have the correct data type. This is only a warning, so Vault will not stop the form, but invalid formulas will evaluate to blank/null.
Invalid table formula A specified variable is not valid or does not exist. For example, a form field maps to a document field that doesn't apply to the source document.
The Secondary Brands field could not be repopulated because you cannot view all documents in the binder. You do not have permission to view one or more documents in the binder. This includes the forms you are generating, so make sure that you have at least permission to view every document in the binder.
Regeneration failed because you do not have permission to either view or version the form in its current state. You are not in a role that has view and version permission for the current lifecycle state of the form. Check the Sharing Settings of the generated form, and ensure that you have permission to version in the current lifecycle state.
[1]: #mapping [2]: #formulas