# Configuring Report Level Publishing (RIM) Report level publishing enables users to publish study report documents from within the Content Plan Hierarchy Viewer. This article discusses how to set up the report level publishing configuration options. See [Configuring Submissions Publishing](/en/lr/48602/) for information about setting up Submissions Publishing.
## Configuration Components The following components support report level publishing: ### Document Types The publishing process creates a binder and published document with the standard _Submission Ready_ document type. This separates published documents from the source documents in the content plan. Additionally, Vault assigns the binder and documents the _Clinical Study_, _Nonclinical Study_, or _Report_ document subtype based on the _Report Level Content Plan_ object type from which the content plan was created. You can also define the document type for published Report Level Content Plan (RLCP) content on the _Content Plan Item_, _Content Plan Item Template_, or _Report Level Content Plan_ record. You can use the _RLCP Output Document Type_ (added on the _Content Plan_ and/or _Content Plan Item_ object) or the _Output Document Type_ field (added on the _Report Level Content Plan_ object) to classify RLCP content to be published as a classification that is not _Submission Ready_. When publishing, if the **_RLCP Output Document Type_** field is populated, Vault sets the published document to the Type, Subtype, and/or Classification defined on the field. Alternatively, if the **_Output Document Type_** field is populated, all content is published as the Type, Subtype, and/or Classification set on the field. ### Document Fields The _Created from_ document field associates a published binder with the root report level content plan from which it was created. With the _Ready for Publishing_ document field, Vault determines which documents to publish when running the _Publish Report_ action. ### Document Lifecycles Vault includes the standard _Submission Ready Lifecycle._ All published binders and documents are automatically assigned the _Submission Ready Lifecycle_. The lifecycle is provisioned with the _Published_ state assigned the _Starting_ state. You can configure additional states, workflows, and security for a full review and approval of published documents. ### Content Plan & Content Plan Item User Actions {#content_plan_content_plan_item_user_actions} The _Content Plan_ and _Content Plan Item_ object lifecycles include the following user actions to support the review and approve content flow: * **Publish Study Report**: Initiates the publishing process for a report level content plan. * **Open Published Documents**: Opens the published document in the document viewer with navigable cross-document links. You can configure this action to only display when the _Published Document_ field is populated on the _Content Plan Item_. This action is only available in the _Content Plan Item_ lifecycle. * **Export Submissions Ready Binder**: Export the published binder. * **Generate Publishing Table of Contents**\*: Generates or recreates a Table of Contents (TOC) document from the template referenced on the related _Publishing Element_ record and matches it to the _Content Plan Item_. \* This action is only available in the _Content Plan Item_ lifecycle. ## Report Level Publishing Configuration You can allow users to publish study reports after they match documents and finalize the report level content plan. To set up report level content plans, complete the following steps: 1. Configure a [_Publish Report Content Plan_][2] object workflow. 2. Configure the [_Publish Report_][3] user action. 3. On the _Content Plan_ object lifecycle, configure the _Export Binder_ user action with the same conditions used for the _Publish Report_ user action. 4. On the _Content Plan Item_ object lifecycle, configure the _Open Published Document_ user action. 5. On the _Submission Ready_ document lifecycle, configure the _Export Submission Ready Binder_ user action. 6. Set up [object types][4] to support the _Merge PDF into a single PDF file_ option. 7. Configure the [publishing document types][5] and document fields. 8. Create _Publishing Element_ records, overlays, and TOC template documents to allow Vault to automatically generate and publish TOCs and overlays. See information about [configuring the TOC][19] and [configuring overlays][20] below. 9. Configure the [_Default Overlay_][20] field. 10. Enable [link annotations and linked documents][6]. You can also enable [dynamic linking][7], if desired. 11. Optional: Ensure only the correct users have access to the [**View Submission Ready Binder**][8] action. 12. Optional: Configure [publishing validation][9] in your Vault. ## Configuring the Publishing Workflow {#configuring-publishing-workflow} To allow users to publish or publish and merge report level content plans and items, you'll need to configure a workflow (with or without the option to merge matched documents) and a user action to initiate the workflow from the _Content Plan_ object lifecycle. When configuring for merging, you'll also need to update _Report Level Content Plan_ object types. ### Configuring the Publish Report Content Plan Object Workflow {#publish-rlcp} Configure a _Publish Report Content Plan_ [object workflow](/en/lr/33550/) with the _Publish Documents and Create Submission Ready Binder_ system action. To allow Vault to publish and merge published documents into a single PDF file, set the **Merge PDF into a single PDF file** checkbox on this step. You can also allow users to choose to publish separate documents or to publish and merge all documents by creating separate workflows with and without this checkbox set, or by configuring branches within a single workflow. Associate the workflows to the _Content Plan_ object lifecycle. ### Section Level Merge When you run the _Publish Study Report_ workflow within an RLCP, Vault identifies all relevant Content Plan sections and their _Content Plan Items_ to be merged during publishing. To do this, the Content Plan section must have the _Merge Section_ field set to “Yes” (true), and the _Title_ and _Section Merge Published Output Location_ (`section_merge_pol__v`) fields must be populated. These and the _Merged Document_ field are required on the _Content Plan_ object. Section Level Merge ### Configuring the Publish Report User Action {#publish-report} On the _Content Plan_ lifecycle, set up the _Publish Report_ user action to start the _Publish Report Content Plan_ workflow based on the _Content Plan_ lifecycle's state, for example, _Locked_ state. This triggers the publishing process for documents matched to a _Content Plan Item._ Publishing is only successful when triggered from the root _Content Plan_ record, and when the _Report Level Content Plan_ field is populated on the _Content Plan_ record. When setting up this action, configure it to perform with conditions that filter on _Report Level Content Plan is not blank_, _Submission is blank_, and _Parent is blank_. These conditions ensure that the action only shows on the root _Content Plan_ record, is available for report level content plans, and does not display for submission content plans. If you do not configure these conditions, users will receive errors if they attempt to publish a report from a _Content Plan_ that is not the root or if the report level content plan is not the appropriate object type. ### Setting Up Object Types for Merging {#object-types} If you enabled the _Merge PDF into a single PDF file_ option in your _Publish Report Content Plan_ workflow, you also need to update _Report Level Content Plan_ object types. To allow Vault to merge published documents into a single PDF during the report level content plan publishing process, [assign the _Merged PDF Document Number_ field](/en/lr/32857/#assign) to all _Report Level Content Plan_ object types. ### Published Links Opening Setting You can choose whether to open external document hyperlinks in a new window or open per the user preference using the _Published Links Opening Setting_ field. When configured, you can select from the following picklist options on the _Clinical Study Report_ (`clinical_study_report__v`), _Nonclinical Study Report_ (`nonclinical_study_report__v`), and _Report_ (`report__v`) Content Plan object types for the _Published Links Opening Setting_ (`pub_link_open_setting__v`) field: * _Open in New Window_ (`open_in_new_window__v`) * _Window Set by User Preference_ (`user_preference__v`) Any links resolved by the publishing process during RLCP publishing respect the Published Links Opening Setting. If the field is not populated Vault sets the opening preference on all links to Window Set by User Preference. ## Setting Up Document Types {#doc-types} Configure the following document types for publishing: * Activate the standard _Submission Ready_ document type and the _Clinical Study_, _Nonclinical Study_, and _Report_ document subtypes. Vault will assign these to the published documents depending on created content plan's object type: _Report Level Plan Clinical Study_, _Report Level Plan Nonclinical Study_, or _Report_ object type. * Activate and add the _Created From_ (`binder_created_from__v`) standard document shared field to the _Submission Ready_ document type. * Optional: Activate the _Ready for Publishing_ (`ready_for_publishing__v`) standard document field and add it to all clinical, nonclinical, and product family document types. By setting the field to **Yes**, users can determine when a document is ready to be published, for example, when a document enters _Steady_ state. We recommend configuring an entry action on the document lifecycle _Steady_ state that automatically sets this field so users do not forget to set it. If you don't add the field to a document type, the publishing process ignores it. ## Table of Contents Configuration {#toc-configuration} Vault can automatically generate and publish TOC documents. To configure this, first create documents to use as TOC templates and upload them to the Vault Library. See details about [configuring a Table of Contents](/en/lr/50478/#toc-doc). Note that your TOC template should not include an eSignature page or errors may occur when Vault generates the TOC. Next, create _Publishing Element_ records: 1. Navigate to **Admin > Business Admin > Publishing Element** and click **Create**. 2. nter a **Name**. 3. In the **Applicable Node Type** field, choose **Table of Contents**. 4. In the **TOC Template** field, select the appropriate template document from the Vault Library. 5. Select the **Page Numbering** for the TOC document. If your configuration merges published documents into a single PDF, select **Overall Page Number (Merge Only)** to allow Vault to create a TOC with sequential page numbers for the merged file. 6. Click **Save**. Finally, update the [object page layouts](/en/lr/26387/) for the following objects to add the _Publishing Element_ field: * _Content Plan Item_ * _Content Plan Item Template_ ## Overlay Configuration Vault allows you to configure an overlay to apply during publishing. You can assign an overlay to a content plan item or create a default overlay on the report level content plan. During publishing, Vault applies the overlay defined in the content plan item's _Publishing Element_ record. If no _Publishing Element_ exists on the content plan item, Vault applies the default overlay. If the _Publishing Element_ exists but does not define an overlay, Vault does not apply an overlay. To configure an overlay on a content plan item, first [create one or more overlay templates](/en/lr/6037/). Next, create a _Publishing Element_ record for the overlay: 1. Navigate to **Admin > Business Admin > Publishing Element** and click **Create**. 2. Enter a **Name**. 3. In the **Applicable Node Type** field, choose **Leaf**. 4. In the **Overlay** field, select the desired overlay template. 5. Click **Save**. Finally, update the [object page layouts](/en/lr/26387/) for the following objects to add the Publishing Element: * _Content Plan Item_ * _Content Plan Item Template_ To configure a default overlay, set the _Default Overlay_ field on the _Report Level Content Plan_ record. ## Annotations & Links ### Enabling Link Annotations & Linked Documents {#enable_link_annotations} Link annotations and document links are available in RIM Submissions Vaults. To enable annotations, navigate to **Admin** > **Settings** > **General Settings** and select the **Links** checkbox beneath _Allow users to bring forward annotations._ To enable linked documents, navigate to **Admin** > **Settings** > **Application Settings** and select the following checkboxes: * **Allow creation of link annotations** * **Enable Create & Import Document Links** * **Allow creation of links to whole documents** * **Bring forward Linked Document relationships to new versions** ### Enabling Dynamic Linking {#dynamic-linking} To enable Dynamic Linking, navigate to **Admin > Settings > Application Settings** and set the **Enable RIM Dynamic Linking** checkbox. When enabled, Vault updates Microsoft Word DOCX documents in the Library to include PDF named destinations for each heading, table, figure, and title style in the document. These persist within the viewable rendition's bookmark targets. After enabling Dynamic Linking, you can also set the **Set Bookmarks & Hyperlinks to Page & Coordinates** checkbox. When enabled, publishing a Report Level Content Plan sets bookmarks and hyperlinks to a page and coordinates to become relative PDF links. The publishing process also converts PDF bookmarks targeting named destinations to target the page and coordinates within the document. ## About the View Submission Ready Binder Action {#view-binder} By default, users can open the _Submission Ready_ binder from a _Content Plan_ or _Report Level Content Plan_ record when the report level content plan is published and references the binder. If desired, you can limit user access to the **View Submission Ready Binder** action. See [Defining User Actions for Objects](/en/lr/43127/) for detailed instructions. ## Publishing Validation Configuration {#publishing-validation} With publishing validation, Vault can verify published study report content based on Health Authority guidelines, such as Link should 'Inherit Zoom', as well as Vault best practices, such as validating that multiple _Content Plan Items_ records with the same matched document have the same value in the _Published Output Location_ field. Vault performs validation during the publishing process. Vault creates individual _Validation Result_ (`submission_validation_result__v`) records to capture each validation result for each _Content Plan Item_ record. ### Renaming EDL Fields We recommend renaming EDL fields on the _Validation Results_ object as follows: * Change the label for the _EDL_ field to **Content Plan**. * Change the label for the _EDL Item_ field to **Content Plan Item**. ### Updating Object Page Layouts To allow users to see individual validation errors, update the page layouts for the following objects to add related object sections for _Validation Result_: * _Submission_ * _Report Level Content Plan_ * _Content Plan_ * _Content Plan Item_ On each object, we recommend adding an _Open Validation Results_ section with a filter: _Occurrences is greater than 0_. This section will display publishing issues that a user needs to verify and correct. We also recommend adding an _All Validation Results_ section to display all validation results for the current record. Next, edit the object page layout for the _Validation Result_ object and select **Create Section > Detailed Publishing Results**. This section allows users to see additional details about validation failures. ### Setting Up Publishing Validation Criteria Vault uses the _Publishing Validation Criteria_ object to validate published content. To set this up: 1. Use [Vault Loader](/en/lr/26597/) to load the Validation Criteria Version to the _Controlled Vocabulary_ object. 2. Use [Vault Loader](/en/lr/26597/) to load the Validation Criteria. Loading these terms creates the necessary _Publishing Validation Criteria_ records. You can modify the _Problem_, _Description_, and _Corrective Action_ fields, but do not modify other fields. After you load _Publishing Validation Criteria_ records, you can view them on the **Admin > Business Admin** page or a custom tab. You can also choose to set the **Exclude from Post Processing on Failure** checkbox field on any _Publishing Validation Criteria_ records to prevent documents that encounter this error from merging during publishing. If you don't set this field, Vault can't merge any documents if one document fails. For example, we recommend excluding the RLCP122 _Publishing Validation Criteria_ record so that if a document is password-protected, Vault can merge all other content successfully. ### Validation Results Archiving In order for Vault to run the _Validation Results Archival_ job, you must [enable attachments](/en/lr/24287/) on the _Report Level Content Plan_ object. This allows the job to add the archive package ZIP file as an attachment on the _Report Level Content Plan_ record 365 days after the _Last Published Date_. You can also edit the _Validation Results Archival_ [job definition](/en/lr/22897/) to select a specific user or group as the **Job Owner**. The job owner will receive notifications if the job encounters a failure. By default, the job owner is _System_, meaning that no user will receive an email if the job fails. If your Vault uses [submissions publishing](/en/lr/48611/), the job owner you set will also receive notifications when Vault archives those validation results. Note that you cannot set the job to inactive. [2]: #publish-rlcp [3]: #publish-report [4]: #object-types [5]: #doc-types [6]: #enable_link_annotations [7]: #dynamic-linking [8]: #view-binder [9]: #publishing-validation [19]: #toc-configuration [20]: #overlay-configuration