# Creating Content Plan Templates (RIM) Content plan templates define the structure and hierarchy when users create new content plans.
## About Content Plan Templates You create content plan templates using the _Content Plan Template_ and _Content Plan Item Template_ objects. The _Content Plan Template_ object allows self-referencing relationships, so you will use one record as the highest level in the template and additional records to create sections and subsections. _Content Plan Template_ and _Content Plan Item Template_ records form the basic structure of the content plan that Vault creates: * _Content Plan Template_ records correspond to _Content Plan_ records comprising the content plan hierarchy's sections and subsections. * _Content Plan Item Template_ records correspond to _Content Plan Item_ records, or the leaf nodes where documents are expected. ### About Dynamic Content Plan Creation In addition to the configured template record hierarchy, Vault uses template record metadata to dynamically create content plan records. For example, a [token][5] in a _Content Plan Template_ record's _Name_ field generates sections (_Content Plan_ records) or expected documents (_Content Plan Item_ records) that repeat based on the Submission's relationships. Similarly, some _Content Plan Template_ and _Content Plan Item Template_ field values specify the scenarios in which Vault should create Content Plan records, based on the Submission's metadata and relationships. Some use cases for this include: * Populating "United States" as the _Lead Market Country_ (`country__rim`) in a _Content Plan Template_ record to specify that Vault should create a _Content Plan_ record (section) only when the United States _Country_ record is related to the _Submission_ (on the related _Application_ record). When creating the content plan, Vault populates values for any fields that have the same _Name_ on both the _Content Plan Template_ and the _Content Plan_ objects. * Populating the _XML ICH DTD / XSD Version_ or _XML Regional DTD / XSD Version_ fields to create Content Plans for [multiple XML versions][9] which are concurrently accepted by a Health Authority. #### About XML Version-Specific Content Plan Templates {#about-xml-version-specific-content-plan-templates} Vault can use the _XML ICH DTD / XSD Version_ and _XML Regional DTD / XSD Version_ fields to dynamically create content plans based on: * The eCTD or XML versions used for the Submission to account for regulatory updates over time. * Multiple eCTD or XML versions which are accepted for a short period of time. For example, the current US regional XML schema version is 3.3. If the FDA updates the schema to v3.4 while still supporting v3.3, Vault can accommodate Content Plans based on two sets of template records: One where template records specify the _XML Regional DTD / XSD Version_ as 3.3, and another where template records specify version 3.4. The _XML ICH DTD / XSD Version_ field is also useful for setting an index _Content Plan Item_ with ICH 3.2 so that when a non-eCTD Submission Content Plan is created, Vault does not create an index _Content Plan Item_. To create content plans based on XML version, select the appropriate _XML ICH DTD / XSD Version_ or _XML Regional DTD / XSD Version_ value on the following supported _Content Plan Template_ and _Content Plan Item Template_ types: * _Regional (Module 1)_ * _Summary (Module 2)_ * _Quality (Module 3)_ * _Nonclinical (Module 4)_ * _Clinical (Module 5)_ * _Other_ ## Creating Content Plan Templates To create a content plan template: 1. Navigate to the _Content Plan Templates_ record list through **Business Admin** or a custom tab. 2. Click **Create** and set up the highest level content plan in this template. The **Name** should be something understandable for users who are creating _Submission_ or _Report Level Content Plan_ records and filling in the _Content Template_ field. 3. Click **Save + Create** to save and start adding child-level _Content Plan Template_ records. 4. Enter details for the first section within the template. You may want a numeric value in **Name** to help organize the sections, for example, _1 Administrative Information_ for the first section and _1.1 Correspondence_ for its first subsection. If a section should use a token, enter the token in the **Name** field. In the **Parent** field, select the _Content Plan Template_ record you created earlier to set a hierarchical relationship between the current record and the first record. 5. Optional: Populate fields like _XML ICH DTD / XSD Version_ or _XML Regional DTD / XSD Version_ to create content plans based on the [XML version][9]. Similarly, you can populate fields like _Region_ (`region__rim`) and _Lead Market Country_ (`country__rim`) to specify that the _Content Plan Template_ record of the template only applies to specific submissions, based on the submission's metadata and relationships. For example, specifying _Lead Market Country: United States_ on a section means that Vault only creates that section if the United States _Country_ record is related to the _Submission_ (on the related _Application_ record). When creating the content plan, Vault populates values for any fields that have the same _Name_ on both the _Content Plan Template_ and the _Content Plan_ objects. 6. Optional: If configured by an Admin, populate the _Exclude from Auto-matching_ field on the _Content Plan Template_ record. When selected, Vault will not enable auto-matching to this _Content Plan_ section when the content plan enters the lifecycle state that turns on auto-matching. See About the Exclude from Auto-Matching Field. 7. Click **Save + Create** to add the next section. 8. Continue to repeat this process until the structure of the content plan is complete. If you need to step back and see the hierarchy as you go, open the Hierarchy Viewer. _Content Plan Templates_ do not use the grid-based Content Plan Hierarchy Viewer. 9. In the Hierarchy Viewer, open the **Create** menu and select **Content Plan Item Template**. Individual _Content Plan Items_ represent a document that you intend to collect for the submission. You can include [tokens][3] in the **Name** field. Click **Save + Create** to save and add the next _Content Plan Item_. 10. Optional: Populate fields like _Region_ (`region__v`) and _Lead Market Country_ (`lead_market_country__v`) to specify that the _Content Plan Item Template_ record only applies to submissions with a matching region and lead market. For example, specifying _Lead Market Country: China_ on an item means that Vault only creates that item if the China _Country_ record is on the related _Application_ record. 11. Repeat this process until the template includes _Content Plan Items_ that represent each document. Alternatively, you can create _Content Plan Template_ records in bulk using Vault Loader. ## Using Tokens {#using-tokens} You can add tokens to the _Name_ field within your _Content Plan Template_ hierarchies to create sections (child-level _Content Plan_ records) or expected documents (_Content Plan Item_ records) that repeat based on the submission's relationships. Vault creates repeating sections in alphabetical order. You can also add _Application_ and _Submission_ tokens to the top-level _Content Plan Template_ to help with auto-naming. These don't repeat. For example, using a _Content Plan Template_ record named **(1)** "3.2.S Drug Substance - ${submission\_active\_substance\_\_regulatory}" to create a content plan generates sibling content plans **(2)** for each _Submission Active Substance_ record **(3)**: Submission Active Substance Content Plan This functionality is available for the _Submission_ object and specific objects with a join relationship to the _Submission_ object. Join object records connect a specific _Submission_ record to other records in your Vault to define the scope of the submission. For example, _Submission Country_ is the join object between _Submission_ and _Country_. See also [Limitations][6] and [Supported Tokens][7] for token-specific behaviors. ### Finding and Setting Tokens Before beginning template creation, you'll need to collect the _Object Name_ and other field name values for any objects related to the _Submission_ object. These values can become tokens within your template. To find these values, navigate to **Admin** > **Configuration** > **Objects** and locate and open the related object. The **Details** tab displays the **Object Name**, and **Field Names** are found in the corresponding column within the **Fields** tab. For example, the name for _Submission Clinical Studies_ is `submission_clinical_studies__rim`, and the name of one of its object fields, _Clinical Study_, is `clinical_study__rim`. #### Setting Tokens Tokens for content plans follow the same general format as system-managed object record names: When resolving a token referencing an object field, Vault displays the value from the field defined after the object in which it appears. Otherwise, Vault resolves the object _Name._ For example: * To populate with the _Submission Clinical Study_ field _XML Clinical Study ID_, use the token `${submission_clinical_study__rim.xml_clinical_study_id__v}` * To populate with the _Submission Language_, use the token `${submission_language__rim}` When creating _Content Plan Template_ and _Content Plan Item Template_ records, you can add tokens to the below fields. * _Name_ * _Title_ (`xml_title__v`) * _Filename_ (for _Content Plan Item Templates_ only) * _Folder Path_ (for _Content Plan Templates_ only) * _XML Element Name_ (for _Content Plan Templates_ only) Token values within the _Title_, _Filename_, _Folder Path_, and _XML Element Name_ fields resolve in the content plan, but will not create repeating sections. Additionally, the _Folder Path_ and _Filename_ fields combine to set the _Published Output Location_ on a created _Content Plan Item_ record. ### Supported Tokens {#token_support} Vault supports tokens for _Submissions_, _Content Plans_, _Report Level Content Plans_, and matched documents. #### Submission Vault supports tokens for object reference and text fields on the _Submission_ object. Long Text, Rich Text, and Formula fields, and fields referencing the _User_ object are not supported. #### Submission Content Plan Vault supports tokens for object reference and [text fields][8] on the below submission join objects. Long Text, Rich Text, and Formula fields, and fields referencing the _User_ object are not supported. * `${related_submission__rim}` * `${submission_pharmaceutical_product__rim}` * `${submission_active_substance__rim}` * `${submission_inactive_ingredient__rim}` * `${submission_indication__rim}` * `${submission_clinical_study__rim}` * `${submission_nonclinical_study__rim}` * `${submission_country__rim}` * `${submission_language__rim}` * `${submission_pharmaceutical_form__v}` * `${submission__v.xml_submission_id__v}` * `${submission_pharmaceutical_form__v}` Additional token resolution behavior in Submission Content Plans includes: * When a token is used in a record where the field is blank, the token text is not resolved. Unresolved tokens are resolved when you add a value to the field and run the _Update Content Plan_ action. * When a tokenized field value is updated, the _Update Content Plan_ action updates the token text and refreshes the value from the template. * When Vault detects differences in non-token text (leading up to a token) between corresponding _Content Plan Item_ and _Content Plan Item Template_ records, the text and the token are not refreshed. #### Report Level Content Plan Vault supports the below tokens for Report Level Content Plans. The report level plan join record _Name_ is used to resolve the token value. * `${report_level_plan_clinical_study__v}` * `${report_level_plan_nonclinical_study__v}` * `${report_level_plan_product_family__v}` #### Matched Document Vault supports tokens for object reference and text fields on matched documents. For example, you can set the `${matched_document.clinical_site__v}` token in the filename to organize _Case Report Forms_ in the appropriate site folders for the _Published Output Location_. Long Text, Rich Text, Autonumber, and Formula fields are not supported. When using tokens in object fields, if the referenced object field is multi-select and has multiple associated records, only the first value is resolved in the token. Examples of commonly-used tokens include `${matched_document.name__v}` and `${matched_document.title__v}`. When used, Vault resolves the token with the value from the field defined after `matched_document`. For example, if using the `${matched_document.ectd_title__v}` token, the `ectd_title__v` field value is resolved in the token. Vault only resolves matched document tokens when the document count equals the expected document count. If the expected document count is one (1), the token resolves when there is a single document matched to the _Content Plan Item._ ### About the _Output Name_ Field {#about-the-output-name-field} You can leverage the _Output Name_ text field to define a unique value to tokenize in the content plan that is not represented by an existing field, such as a shortened name. For example, a clinical study section references the _Submission Indication_, defined as "Multiple Sclerosis" through the `${submission_indication__rim}` token. However, this indication must be expressed in a different format within the _Published Output Location_. The alternate indication name ("multiplesclerosis") can be defined in the _Output Name_ field. ### About Clinical and Nonclinical Study Tokens Vault creates repeating sections for clinical and nonclinical studies only when the _Study Type_ and _Study Subtype_ defined in the _Submission Clinical Study_ or _Submission Nonclinical Study_ record record match the _Study Type_ and _Study Subtype_ defined on the template record containing the clinical study or nonclinical study token. For example, a content plan template defines the ${submission_clinical_study__rim} token in Section 5.3.1.1 with a _Clinical Study Type_ and _Clinical Study Subtype_ of **Biopharmaceutical** and **Bioavailability (BA)**: Clinical Type and Subtype A _Marketing Submission_ (**0000**) has two related clinical studies, **ABC-123** and **CL 123**, where ABC-123's _Clinical Study Type_ and _Subtype_ are defined and match the template, and CL 123's _Clinical Study Type_ and _Subtype_ are not yet populated. No Clinical Type and Subtype In the resulting content plan, Section 5.3.1.1 includes a subsection with a **Biopharmaceutical** _Type_ and **Bioavailability (BA)** _Subtype_, which match the respective values defined for **ABC-123**. A section for **CL 123** will not be created until the type and subtype are defined on the _Submission Clinical Study_ record. If there is a template record with a blank type and subtype and the clinical study token in the _Name_, a section would be created for both ABC-123 and CL 123. Resulting Content Plan ### Limitations {#limitations} * It is recommended you use a _Submission_ join object token for only one join object at a time, as only one such token can be resolved for a Content Plan record at one time. For example, if a _Content Plan Template_ record _Name_ is defined as `${submission_clinical_study__rim} - ${submission_nonclinical_study__rim}`, only the `${submission_clinical_study__rim}` token is resolved. * Token sections can be nested. For example, a _Content Plan Template_ section using `${submission_language__rim}` can be nested under a section using `${submission_country__rim}`, which creates a section for each _Submission Language_ under the appropriate _Submission Country_ section. * When multiple tokens from one or more different objects are used in a _Content Plan Item_ or _Content Plan Item Template_, Vault attempts to populate all tokens if the Submission join reference is populated on the _Content Plan Item_. If the join reference is blank, the token is not resolved. ### Additional Configuration for Tokens To use a token in a content plan template, you must ensure that the corresponding _Submission_ join fields and matching fields are added on the _Content Plan_ object types. For example, if you add the `${submission_pharmaceutical_form__v}` token to a Regional (Module 1) _Content Plan Template_ record, ensure that the _Submission Pharmaceutical Form_ and Pharmaceutical Form fields are added to the Regional (Module 1) _Content Plan_ object type. Otherwise, errors will occur during content plan creation. [3]: #token_support [5]: #using-tokens [6]: #limitations [7]: #token_support [8]: #about-the-output-name-field [9]: #about-xml-version-specific-content-plan-templates