# Configuring Submissions Publishing (RIM) The Submission Publishing application enables users to publish documents from within the Submissions Archive Viewer and the Content Plan Hierarchy Viewer, allowing Vault to progress those published documents through various lifecycle states for review and approval. You can accomplish this by configuring user actions that apply to the _Content Plan_ and _Content Plan Item_ object lifecycles, and the _Submissions Archive_ document lifecycle.
## Associated Configuration Options Submissions Publishing Vaults are provisioned with various configuration options to support the publishing process: ### Submission Archive Lifecycle States The _Submissions Archive_ document lifecycle includes the following states: * **Published**: Entry state for published documents that have not been reviewed. * **In Publishing Review**: For published documents currently under review. * **Ready to be Submitted to HA**: For published documents that have undergone review and are ready to submit to the Health Authority. * **Rejected**: The state of published documents that were rejected upon review and require corrections before they can be considered submission ready. ### Submissions Archive Lifecycle User Actions The _Submissions Archive_ document lifecycle includes the following user actions to support the publishing process: * **Open Content Plan**: Opens the associated _Content Plan_ for the published document. * **Open Content Plan Item**: Opens the associated _Content Plan Item_ record for the published document. * **Open Source Document**: Opens the source document used to create the published document. These actions are not available for the _Final_ state. ### 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: * **Open in Submissions Archive**: Opens Submissions Archive Viewer to the corresponding submission, expanded to the corresponding section. * **Open Published Document**\*: 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_. * **Run On-Demand Validation**: Refreshes validation results based on recent changes. * **Open Matched Document**: Opens the matched document in the document viewer. * **Run On-Demand Publishing and Validation**: Publishes the selected item and its descendants, and refreshes validation results. Any affected XMLs are also published and validated. * **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_. * **Edit Table of Contents**\*: Allows users to update a generated TOC, including renaming, promoting/demoting, and activating/inactivating TOC structure components. * **Set Reference Leaf**\*: Allows users to set a Submissions Archive document as a [reference leaf][13]. We recommend configuring the action in the _Baselined_ state. *Action is available in the _Content Plan Item_ lifecycle only. ### Link Annotations Link annotations and document links allow users to link to specific pages or paragraphs within other documents, the current document, or to complete documents. When users create cross-document links, Vault gathers those links and converts them to standard PDF links with a relative path to the target at the time of publishing. This allows users to easily navigate to referenced pages within a target document. ## Configuration Overview Configuring the Submissions Publishing application involves several steps. To allow users to fully utilize the features to support the publishing process, we recommend working with Veeva Support to configure publishing. 1. Set up the _Open Content Plan_, _Open Source Document_, and _Open Validation_ _Results_ document lifecycle user actions . This allows users to view content plans, source documents, and validation results directly from published documents. 2. Set up user actions on the _Content Plan_ and _Content Plan Item_ object lifecycles to support the publishing process. 3. Set up the _Publishing Complete_ entry criteria on the _Submission_ object lifecycle. This prevents _Submission_ records from entering states when pending publishing jobs exist. 4. Configure _Content Plan Templates_ based on the eCTD or non-eCTD structure. 5. Configure content plan constraints . 6. Recommended: Configure the _Content Plan Item_ lifecycle to allow users to set a Submissions Archive document as a [reference leaf][13]. 7. Update object page layouts to support the publishing and validation process. See below for [detailed instructions][6]. 8. Create _Publishing Element_ records and TOC template documents to allow Vault to automatically generate and publish TOCs. See below for [detailed instructions][7]. 9. Enable [link annotations and linked documents][8]. You can also enable [dynamic linking][9], if desired. To enable cross-application links, set the _Allow Cross Application Linking_ field to **Yes** on the _Country_ record selected as the application's lead market. When enabled, Vault can create links to documents in a different application as long as the applications have the same _Lead Market_, _Health Authority_, and _Health Authority Division_. 10. Enable Vault to automatically calculate and assign a _Sequence ID_ (`xml_submission_id__v`) when users create a new _Submission_ record. 11. Enable attachments on the _Submission_ object. This allows the _Validation Results Archival_ job to add the archive package ZIP file as an attachment on the _Submission_ record 365 days after the submission is complete. 12. Configure a shared field or matching document fields with the same field type and _Name_ on the _Submissions Archive_ document type and any document types for source documents. Matching fields allow Vault to automatically populate fields on the published document with field values from the source document. If needed, set up Dynamic Access Control rules that match the rules for source documents to ensure that only the appropriate users can see the published documents. 13. Optional: From **Admin > Operations > Job Definitions** , update the **Job Owner** for the _Validation Results Archival_ job to the user or group who should 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 report level content plans , the job owner you set will also receive notifications when Vault archives those validation results. You cannot set the job to inactive. ## Table of Contents Configuration {#toc-setup} 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 . ### Configuration Overview 1. Configure a _Controlled Document Template_ so that TOC template documents can be stored in the Vault Library, then create a new TOC template document which will become the basis of TOCs users will generate. See [Creating a Table of Contents Document][10], below. 2. Configure the **Generate Publishing Table of Contents** user action on the _Content Plan Item_ object lifecycle. We recommend configuring this action on the _Baselined_ state. 3. Configure the **Edit Table of Contents** user action on the _Content Plan Item_ object lifecycle to allow users to modify published TOCs , for example _Draft_ and _Baselined_. This action is supported for _Content Plan Items_ with a _Publishing Element_ record, when the element record's _Page Numbering_ field is set to "Document Level Page Number". See [additional details][11] about creating _Publishing Elements_. 4. Review your Vault's security configuration and ensure users are assigned the appropriate [permissions][15] to work with TOCs. 5. [Create][11] a _Publishing Element_ record referencing the TOC template document. 6. [Create or update][12] Content Plan Item Template records to specify a created TOC's location in the Vault Library. ### Creating a Table of Contents Document {#creating-toc-document} To configure a Table of Contents document for a Content Plan: 1. Configure a _Controlled Document Template_ so that TOC template documents can be stored in the Vault Library. See Configuring Controlled Document Templates for detailed instructions. Depending on your Vault's configuration, this step may include creating a new document type . We recommend using a document type specific to TOC templates, with minimal required fields and dependencies. For example, a _TOC_ document type with _Clinical Study Report_ and _Nonclinical Study Report_ subtypes can be helpful when uploading different TOC document templates, depending on the Content Plan Template you're using. 2. Create a TOC template document in Microsoft Word️ and add supported TOC tokens . 3. Upload your Microsoft Word️ .DOCX TOC template document to your Vault. Classify the document according to the _Controlled Document Template_ configuration followed in Step 1. ### Creating Publishing Element Records {#publishing-element} To create _Publishing Element_ records: 1. Navigate to **Admin > Business Admin > Publishing Element** and click **Create**. 2. Enter 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 as created above. 5. Set the **Page Numbering** for the TOC document to **Document Level Page Number**. 6. Click **Save**. To create _Publishing Element_ records for Table of Contents: 1. Navigate to **Admin > Business Admin > Publishing Element** and click **Create**. 2. Enter 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 as created above. 5. Set the **Page Numbering** for the TOC document. While this field is not required by default, records without a value can result in publishing failures and/or an invalid Table of Contents. * When the TOC will not be used in a merged document, select "Document Level Page Number". * When the TOC will be part of a merged document, select "Overall Page Number (Merge Only)". 6. Click **Save**. ### Configuring the Content Plan Item Template {#content-plan-item-template} To configure the _Content Plan Item Template_: 1. Navigate to or create a new _Content Plan Item Template_ record. 2. In the **Full Document Type** field, select the desired document type, subtype, and classification for the created TOC document, for example, _Clinical Study_ > _Table of Contents_. Vault uses this selection to classify the created document. 3. In the **Node Type** (`xml_node_type__v`) field, select **Table of Contents** from the drop-down. This indicates that Vault should create the document as a Table of Contents. If you don't select this node type, the user actions will not be available. 4. In the _Source for Published Document field_ , to support custom Rendition Types, add the values to the _Source for Published Document_ picklist. Ensure that the text string of the _Picklist Value Name_ exactly matches the _Rendition Type Name_. ### Related Permissions {#toc-permissions} For each *Content Plan Item* lifecycle state in which the *Edit Table of Contents* action is configured, all applicable roles must have *Read* and *Edit* access, as well as *Execute* atomic security permission. Users generating TOCs via the *Generate Table of Contents* action must have: * *View Document*, *View Content*, *Edit Document*, *Edit Relationships*, and *Manage Viewable Rendition* permissions within each relevant document lifecycle state for the lifecycle assigned to the *Table of Contents* document type. For example, if the *Table of Contents* document type is assigned to the *General Lifecycle*, these permissions would be configured on the *Draft* state. * *Read* permission for the relevant *Publishing Element* record, as well as a permission set with *Read* permission for this object. * *Read* permission for the TOC template. ## Reference Leaf Configuration {#reference-leaf-configuration} To allow users to set a Submissions Archive document as a reference leaf : 1. Activate the _Set Reference Leaf_ system action on the _Content Plan Item_ object. 2. Ensure the users in your Vault have the [appropriate permissions][14] to set reference leafs. ### Related Permissions {#reference-leaf-permissions} To set a reference leaf, a user must be assigned a _Full User_ license for the RIM Submissions Publishing and RIM Submissions Archive applications. Additionally, within the _Content Plan Item_ object lifecycle, you must ensure users have the ability to execute the action and edit certain _Content Plan Item_ fields through Atomic Security. We recommend using the _Baselined_ lifecycle state for the following Atomic Security parameters: * Any role to which users are assigned (for example, _Document Contributor_) must have _Edit_ permission in all applicable lifecycle states. * Any role to which users are assigned must have Atomic Security _Edit_ permission for the following fields : _Node Type_, _Published Output Location_, _XML Operation_, and _XML Modified File_. This permission must be configured for applicable object types, or you can apply them to _All Object Types_. Confirm or select this information in the dropdown below the **Atomic Security: Fields** heading. Finally, users must be assigned to a permission set with the following minimum requirements to set a reference leaf: | Type | Permission Label | Controls | |---|---|---| | Permission Set | Object: Content Plan Item: Read | Ability to view records in the _Content Plan Item_ object. | | Permission Set | Object: Content Plan Item object types: Read | Ability to view records in the applicable _Content Plan Item_ object types. | | Permission Set | Object: Submission: Read | Ability to view records in the _Submission_ object. | | Permission Set | Object: Submission object types: Read | Ability to view records in the applicable _Submission_ object types. | ## 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 submission. 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 . 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**. To set the default overlay on a submission, you must use the _Set Default Overlay_ user action on the _Submission_ record. You cannot configure the _Default Overlay_ field directly. ## Updating Object Page Layouts {#page-layouts} Make the following updates to various object page layouts to support the publishing process: * Add the _Open Validation Results_ field to the _Content Plan Item_ object page layout. * _Content Plan Item_ * _Content Plan Item Template_ * Add the _Publishing Status_ field to the page layouts for all object types of the objects below. This ensures that users can see the publishing and validation progress for the whole content plan as well as for each component. * _Submission_ * _Content Plan_ * _Content Plan Item_ * Add a related object section for the _Submission Validation Result_ object to page layouts for all object types of the following objects: * _Submission_ * _Report Level Content Plan_ * _Content Plan_ * _Content Plan Item._ * Edit the object page layout for the _Submission Validation Result_ object and select **Create Section > Detailed Publishing Results**. This section allows users to see additional details about validation failures. ## Enabling Link Annotations & Linked Documents {#links} Link annotations and document links are available in RIM Publishing Vaults. To enable annotations, navigate to **Admin > Settings > General Settings** and select the **Links** and **Restore Placemarks on Brought Forward Annotations** checkboxes 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. ## Creating Keyword Links You can define _Keywords_ and additional match text variations that target a defined link destination. While you can define more than one target, Submissions Publishing only resolves the first target created. Users can then create four types of link annotations: * **Suggested Links**: When a user clicks the _Suggest Link_ button on a document, Vault generates Suggested Links for non-exact text matches, which the user must review and accept or reject. * **Approved Links**: When a user accepts a Suggested Link, it becomes an Approved Link. * **Auto Links**: When users click the _Suggest Link_ button on a document, Vault generates Auto Links for exact text matches, which do not require review or approval. * **Keyword Links**: Users can select the _Keyword_ type to manually select a _Keyword_ based on matching fields. _Keywords_ are managed as object records within Vault. To define _Keywords_: 1. Navigate to **Business Admin** > **Keywords** and click **Create**. 2. Enter the **Match Text**. This is the wording that will be used to suggest links. By default, the match text must be at least ten (10) characters. 3. Optional: Select a **Category** for the _Keyword_. 4. Click **Save**, or to enter another _Keyword_, click **Save + Create**.
### Enabling & Disabling the Suggested Link Action _Keyword_ linking must be enabled on the specific document types, subtypes, or classifications where you want it to be available, and link annotations must be enabled in your Vault's _Application Settings_. To configure the **Suggest Links** action: 1. Navigate to **Admin** > **Settings** > **Application Settings**. 2. In the _Linked Documents_ section, set the **Allow creation of link annotations** checkbox. 3. Navigate to **Admin** > **Configuration** > **Document Types**. 4. From the **Actions** menu next to the document type or subtype you want to enable, select **Edit Details**. 5. Under _Enable "Suggested Links" Action_, select **Enable Action** or **Do not Enable Action**. For document types, you can choose **Inherit from Base Document** to allow or disallow the _Suggested Links_ action based on the setting of the base document type. Similarly, document subtypes and classifications can inherit enablement from their parent document type. Alternately, you can choose to enable or not enable the action individually for each specific document type, subtype, or classification. 6. Click **Save**. ### Enabling & Disabling Document Types as Targets for Suggested Links When you enable a document type as a target for Suggested Links, all documents of that type become eligible for selection in the _Select Anchors_ dialog when a user adds references to a _Keyword_. When you disable a document type, all documents of that type become ineligible for selection in the _Select Anchors_ dialog, and all anchors or documents of that type are removed from any _Keyword_ records in which they appear. If you later re-enable the document type as a target, Vault restores the removed references. To configure **Suggested Links** targeting for a document type: 1. Navigate to **Admin** > **Configuration** > **Document Types**. 2. From the **Actions** menu next to the document type or subtype you want to enable, select **Edit Details**. 3. Under _Enable "Suggested Links" Target_, select **Enable as Target** or **Do not Enable as Target**. For document types, you can choose **Inherit from Base Document** to allow or disallow the _Suggested Links_ targeting based on the setting of the base document type. Similarly, document subtypes and classifications can inherit enablement from their parent document type. Alternately, you can choose to enable or not enable targeting individually for each specific document subtype. ### Disabling Manual Linking to Keywords By default, Vault allows users to add _Keyword_ links to documents manually by selecting approved _Keyword_ records when adding annotations. To disable this feature, navigate to **Admin** > **Settings** > **General Settings** and, in the _Documents_ section, clear the **Allow linking via selection of approved Annotation Keywords records** checkbox. ### Disabling Auto Links To disable Auto Links, navigate to **Admin** > **Settings** > **General Settings** and, in the _Documents_ section, clear the **For Suggested Links, bypass Approve step on exact matches** checkbox. ### Moving Keyword Links To bring forward and move _Approved_ or _Auto-Accepted_ links that were created in a previous version of the link source, select **Move** from the **Annotation** action menu. When using the **Move** action, auto-created _Keyword Links_ are converted to manual annotations. If an Auto-Link is brought forward onto a document version that does not contain matching text, the Auto-Link is created as a page-level annotation. The page-level annotation does not have the option to be moved. ### Adding Match Text Variations Sometimes, the same _Keyword_ can be worded in multiple ways. You can configure each _Keyword_ record to match with variations on the match text by using Match Text Variations and wildcards. Match Text Variations allow you to add up to five (5) alternate phrases to each _Keyword_ record. For example, a _Keyword_ might have the match text "Cholecap can significantly reduce LDL-C when used as directed." Adding "When used as directed, Cholecap can significantly reduce LDL-C" as a Match Text Variation allows you to track both variations in the same _Keyword_ record. Match Text Variations have their own lifecycle, and must be in the _Approved_ state in order to be used by Suggest Links. Contact Veeva Support if you need to add more than five Match Text Variations to a _Keyword_ record. To add a Match Text Variation: 1. From the _Keyword_ record detail page, open the **Match Text Variations** panel and click the **Create** button. 2. Enter a **Name** for the match text variation. 3. Enter the alternate **Match Text**. 4. Click **Save**, or click **Save + Create** to enter additional match text variations. ### Using Wildcards _Keywords_ often include variable content such as adjectives, footnote references, and trademark symbols. Using wildcards in match text allows Vault to match content in a document to a _Keyword_ record, even when variable words and characters exist. You can use wildcards in both primary match text and in Match Text Variations. Wildcards are formatted as {*}. There are two types of wildcards. Standalone wildcards have a space on each side and can represent up to ten (10) whole words. For example, "Cholecap is {*} good" would match "Cholecap is good," "Cholecap is very good," and "Cholecap is the gold standard of good." Vault ignores standalone wildcards at the beginning and end of match text. Attached wildcards are used at the beginning, middle, or end of a word and add an unlimited number of characters to that word only. For example, "Chole{*} works well" matches "Chole works well", "Cholecap works well", and "Cholecap1 works well". Each match text entry can include up to three (3) wildcards. When two or more wildcards of the same type appear consecutively, Vault only uses the first wildcard and ignores any subsequent consecutive wildcards. For example, either "when taking Cholecap {*} for the first time" or "when taking Cholecap {*} {*} for the first time" matches "when taking Cholecap for the first time" and "when taking Cholecap OTC XR for the first time." When two wildcards of different types appear consecutively, Vault uses both wildcards. Vault counts wildcards as plain text characters when validating minimum and maximum match text length. ### About Excluded Characters _Keyword_ statements often contain certain characters, such as copyright and trademark symbols, whose presence or absence does not affect the meaning of the _Keyword_. Vault ignores these characters when evaluating whether a given text string is identical to a _Keyword_ record's _Match Text_ or _Match Text Variation_. For example, if copyright symbol © is included in Excluded Characters, a _Match Text_ value of "Cholecap works best with a Heart Healthy diet" matches both "Cholecap works best with a Heart Healthy diet" and "Cholecap© works best with a Heart Healthy diet". By default, the set of Excluded Characters is: * Copyright: © * Registered: ® * Trademark: ™ * Servicemark: ℠ ### Editing & Disabling Excluded Characters To edit the list of excluded characters, navigate to **Admin** > **Settings** > **General Settings** and click the **Edit** button. Then, in the _Documents_ panel, add or remove characters in the **Excluded Characters** field. Vault limits this field to 20 characters, including spaces. There is a known issue which causes Vault to ignore wildcards in _Match Text_ and _Match Text Variations_ when {curly brackets}, asterisks(*), or both are included in excluded characters. Note that Vault treats each character independently. For example, if you add the word "always" to the set, Vault will treat each letter ("a" and "l" and "w" etc.) as a separate excluded character. To disable excluded characters, clear the **Exclude specific characters when matching Annotation Keywords to content** checkbox. ### Adding, Previewing, & Removing References _References_ provide proof of the validity of a _Keyword_ link. They can be anchors or entire documents. You can add multiple references to each _Keyword_. You can add a reference from the _Keyword_ record detail page. Click the **Add** button under _References_ and select **Document** or **Permalink** targets. _Document_ targets include links to anchors in documents. _Permalink_ targets include links to documents, pages, bookmarks, and named destinations. _Permalink_ targets are versionless and always link to the latest available version of the referenced document. To add a reference to an anchor, select the **Document** target type to open the _Select anchors_ dialog. To add a _Permalink_ reference, select the **Permalink** target type to open the _Select targets_ dialog. Vault displays a list of all the documents in your library that you have _View Document_ and/or _View Content_ permissions for and have a document type configured to enable referencing from suggested links. You can choose from the list, use the search bar to find targets, or add filters. You can also hover over the name of the document or anchor for more information and click the name to open the document or anchor. In the _Select anchors_ and _Select targets_ dialogs, you can click the **View and select** link below the target name. If you have the _Create Anchors_ permission, this link will read **Select or create** and you can create new anchors or permalinks within the mini-browser. Click on the **plus** (**+**) icon next to each document or anchor you want to add, then click **Close** to add the references. In the _Select anchors_ dialog, you can also click the **Preview Link** icon next to an anchor to view the target in a mini-browser window. From the **Actions** menu next to each reference's name, you can select **Preview** to see a list of existing targets on a record, or select **Remove** to remove the reference and its related _Link Target_ records. You must have _View_ and _Execute_ permissions on the _Preview_ and _Remove_ Object Action Permissions for the _Link Target_ object to use these actions. The _Business Administrator Actions_, _System Administrator Actions_, and _Vault Owner Actions_ standard permission sets include these permissions, but they must be added to other standard permission sets and any custom permission sets. ### Preventing Duplicate Keyword Records When you click **Save** on a _Keyword_ record, Vault prevents you from creating or updating the record if the Match Text value and all other matching field values are identical to another existing _Keyword_ record. As with duplicate prevention for Match Text Variations within a _Keyword_, duplicate prevention for _Keyword_ records treats wildcards in match text as plain text. Therefore, "Trust Chole", "Trust Chole{*}", and "Trust Cholecap" are not duplicate values. However, Vault ignores excluded characters, trailing periods, and exclamation points in duplicate validation, meaning that "Trust Cholecap", "Trust Cholecap.", and "Trust Cholecap!!!" are considered duplicate values. Vault does not evaluate inactive _Keyword_ records for duplicate prevention; however, it does prevent you from making a _Keyword_ record active if it is a duplicate of an active _Keyword_. Vault prevents you from creating whole-document links to the current document version. Therefore, some situations may result in a Suggested Link or Auto Link that does not include a link component for that reference in the resulting annotation. ### About the Keywords Lifecycle The _Keywords_ lifecycle is an object lifecycle which applies to all _Keyword_ objects. Newly created _Keywords_ begin in the _Draft_ state and cannot enter the _Approved_ state unless a user adds at least one (1) valid reference. Only _Keywords_ in the _Approved_ state are available for use in suggesting links. You can add custom lifecycle states and workflows to suit your organization's needs. ### Preventing Invalid Suggested Links To prevent RIM from suggesting invalid links, Vault removes associated references from any _Keyword_ records that reference them and, if the record is in _Approved_ state, returns it to _Draft_ state when: * A user deletes a targeted document or anchor. * A target document enters a lifecycle's _Obsolete_ state. * A target document's document type configuration is changed to be ineligible as a target for Suggested Links. * A target document's document type is changed to a different document type that is ineligible as a target for Suggested Links. ### Related Permissions You must have _Create_, _Edit_, and _Delete_ permissions on the _Keyword_, _Keyword Targets_, and _Link Target_ object in addition to _Admin_: _Configuration_: _Objects_: _Create_ and _Edit_ permissions to create and configure objects. You must have _Create_, _Edit_, and _Delete_ permissions on the _Keyword_, _Keyword Targets_, and _Link Target_ objects to use _Keyword_ Linking. You must have the _Bulk Update_ document permission to perform the _Get Link Annotation Data_ bulk action. [6]: #page-layouts [7]: #toc-setup [8]: #links [9]: #dynamic-linking [10]: #creating-toc-document [11]: #publishing-element [12]: #content-plan-item-template [13]: #reference-leaf-configuration [14]: #reference-leaf-permissions [15]: #toc-permissions