Document Functions

From that version onward:

• Users must have the Document Manager action assigned in order to delete published/finalized documents, including their own.
• Editors without the Document Manager action should not be able to delete finalized documents.

This remains the intended product design.

In version 10.6.2, there was a defect that incorrectly allowed document Owners (Editors) to delete finalized documents without the Document Manager action.

This behavior:

• Was not expected
• Was not configuration-based
• Was a defect

The current functionality (requiring Document Manager) is correct and aligns with the 10.0.5 enforcement.

No, From a product design perspective:

• Editors can delete documents before finalization
• After finalization, deletion requires the Document Manager action

There is no supported scenario allowing an Editor without Document Manager to delete a Final-status document, even if they are the document owner

The Document Manager action allows users to:

• Delete finalized documents
• Update metadata after publication
• Change index position after publication
• Perform actions on documents owned by other users

This is why assigning Document Manager grants broader archive-level authority and not just 'self-document deletion' capability.

Yes, The current design intentionally requires the Document Manager action for:

• Any post-finalization deletion
• Including deletion of self-owned documents

This is consistent with compliance and audit control principles.

No, not under current product design.

Enabling Editors to:

• Delete only their own finalized documents
• Without broader Document Manager privileges

would require a formal product enhancement request (AHA).

However, the current position communicated is that such a change is not desired.

No general issue has been identified.

If Editors are unable to delete archived documents:

• This is expected behavior unless they have the Document Manager action assigned.
• If deletion was previously working without that action, it was due to the 10.6.2 defect.

Further investigation would require:

• Exact steps taken
• User role and action configuration
• Version confirmation

The confusion stems from:

• The 10.6.2 defect temporarily allowing deletion without Document Manager
• Earlier communication stating deletion was possible
• Lack of awareness that the defect contradicted original 10.0.5 enforcement

Once the defect was corrected, behavior reverted to intended system design.

The Purge functionality allows permanent removal of documents from a room. This action is restricted to Admin users only.

• Auto-purge is currently disabled in all rooms based on the applied templates.
• The Purge action is accessible within the Documents Module > Settings area.
• Once executed, the purge action is recorded in the room audit trail.
• The purge entry will only appear in the audit trail after the action has taken place.

Admins can access deleted documents by:

1. Navigating to the Documents Module
2. Selecting View By
3. Choosing Deleted

From this view, Admins can either: Manually purge the documents, or Restore the documents.

During internal reconciliation review, it was observed that certain rooms do not display the purge/delete option. This may be due to:

• Room-level configuration differences
• Template-based restrictions
• Permission configuration inconsistencies

This requires verification to ensure that the purge functionality is consistently configured where appropriate.

Yes, the expectation is that the purge/delete capability should be available in all applicable rooms, provided:

• It is restricted strictly to Admin users
• It aligns with template and compliance configuration requirements

A configuration review is recommended to confirm consistent enablement across rooms.

The delete/purge functionality should be restricted exclusively to Admin roles to maintain:

• Compliance integrity
• Audit trail accuracy
• Controlled document lifecycle management

Confirmation is required regarding:

• Whether this restriction is already enforced system-wide

If not, when it will be implemented

• View Only access Users are restricted from downloading, exporting, or printing documents. This is expected system behavior when DRM is enabled.
• Full Access folder permissions Users can download documents from the Document Viewer and the Version History section, even with DRM enabled.
• Document Cart downloads Downloads via the Document Cart are controlled solely by the Enable Export (for all roles) setting. When this setting is disabled, Editor users will receive an “Unauthorized to perform requested operation” error when attempting to download documents from the Document Cart. This behavior reflects the current and intended system functionality.

The Replace Attachment functionality is unavailable when a record is claimed and actively part of a QC workflow. This is expected behavior. Once the record is released from the workflow, the Replace Attachment option becomes available and works as intended.

In UAT, the same user was acting as both the original submitter and the Manager, which allowed Replace Attachment to appear while the record was claimed. This caused confusion during testing.

In Production, users are not allowed to QC their own submissions, so this scenario does not apply. As a result, the behavior observed in UAT should not be expected in Production.

• The Query Manager must ensure the record is not part of an active workflow.
• If the Query Manager has the record claimed, they must release the record.
• If another user has the record claimed, the Query Manager must contact the TMF Admin to request the record be released.
• Once the record is released, Replace Attachment will function as expected.

No. The configuration change initially tested was later confirmed to be not applicable to Query Management – Replace Attachment. The change was reverted, as it did not influence the observed behavior.

• Whether the record is claimed
• Whether the record is part of an active workflow
• Whether the user is the original submitter
• User role and permissions (e.g., Manager, Super Admin)

This option is tied to Document Expiration settings, not Management. Its behavior and placement are expected based on the current system design and were reviewed with the Service Desk and Solution Engineering team.

• The Effective Date is manually set in the metadata during document upload or finalization.
• The Activity Date shown in the Version tab reflects when the effective process was executed in the system.

If a document is uploaded on one date but manually marked effective for an earlier date, the two dates will differ.

No. Page manipulation is not allowed on documents that are part of a query response. This is expected system behavior.

User can add a new Company:

• Click the “+” (plus) icon next to the Company drop-down field.
• This opens a window to manually create a new organization.
• Once created, the Company becomes selectable in the drop-down list.

If this option is unavailable, the Company may need to be created in Settings prior to adding the client, especially under newer IAM behavior.

Manual entry is not allowed directly in the Company field. The Company must already exist in the system or be created using the +icon. Quick Invite will default to email domain, but for named organizations, the Company must be created first.

This is a common misunderstanding. The viewer itself must still be enabled in the room configuration. What was “enabled by default” was an improvement to the viewer’s functionality, not the activation of the viewer for all file types.

There are three viewers with distinct functions:

• Original Viewer: Opens the file directly in the browser.
• TI Viewer (Previous Viewer): Uses ARender to convert most file types to PDF for display.
• Enhanced TI Viewer (TI Editor): Uses OnlyOffice to view (and edit) Microsoft Office files and can also function as a viewer for these file types.

Viewer selection depends on the use case:

• TI Viewer (ARender): Best for general use cases where files are converted to PDF for consistent rendering.

• Enhanced TI Viewer (TI Editor / OnlyOffice): Best suited for viewing and editing Microsoft Office files (Word, Excel, PowerPoint).
• Original Viewer (Native Browser Viewer): Ideal for files already in PDF format or for media files such as videos.

Each viewer excels at different tasks—no single viewer provides optimal performance across all file types and use cases. Maintaining multiple viewers allows users to choose the best tool for their specific document types and workflows.

While it is technically possible to set Markup and Balloons as the default display mode in OnlyOffice, there is currently no configuration available to apply this setting globally across all documents. At this time, it is only configured for specific use cases, such as CTMS visit reports.

There is no direct configuration workaround available within the current system. To request this as an enhancement, it is recommended to create an AHA ticket so the feature can be considered for future development.

Re-uploading the documents in zipped format could be a viable workaround; however, the issue should be investigated first to determine whether a broader, more sustainable solution is available.

Site Visit Documents finalized and signed in the CCR are expected to auto-file into the linked eTMF with a status of Final, bypassing Indexing and Review workflows. The current behavior—where documents are instead available for Indexing and Review—indicates a defect and does not align with the intended functionality.

It is expected behavior for ARender and Adobe not to display Word comments or tracked changes, as these viewers do not support that functionality. To view tracked changes, Microsoft Word or OnlyOffice must be used. Although Word documents were configured to render with OnlyOffice for supported file types (.doc, .docm, .docx, .dotm, .dotx), users noticed that tracked changes were only visible when comments were present. Further testing showed OnlyOffice uses display modes such as Final, Original, and Markup, and may default to a mode that hides changes. Switching to “Markup and Balloons” displays tracked changes correctly.

Document rendering servers (OnlyOffice and ARender) rely on pre-installed fonts within the operating system to maintain consistent document appearance across platforms. When a document requests a font that is not available on the servers, the system substitutes a similar font. If no close match is found, formatting differences may occur.

• Licensed fonts: Require a purchased license and are not installed by default due to legal and cost restrictions. If a document uses a licensed font that is not available, the system substitutes a similar font, which may alter appearance. Clients may need to arrange licensing if these fonts are required.
• Free fonts: Are openly available and can be installed without legal or cost barriers. Documents using free fonts render correctly as long as the required font is installed on the server.

When there is a rendering issue related to font substitution, follow these steps:

• Confirm the issue: Verify whether the issue is due to font substitution by reviewing the document on the rendering servers.
• Check font availability: Determine whether the required font is installed. If it is a licensed font not included by default, inform the client about licensing restrictions.
• Escalate if necessary: If a supported font is not rendering correctly, escalate to the support team for investigation.
• Client communication: Explain that font availability depends on licensing. If a specific licensed font is required, the client may need to coordinate licensing arrangements.

The Implementation Team should:

• Gather information about the font types used by the client.
• Update templates and documentation to ensure font type details are recorded.
• Verify whether required fonts are supported by the rendering servers.
• If an unsupported font is identified, contact the Service Desk to proactively resolve the issue.

Product Managers must:

• Update the user guide to list the font types supported by the rendition servers.
• Regularly review and curate the list of supported fonts to ensure popular fonts are available on the rendition servers.

The list of Audit Activity Types and Actions includes:

• Document Actions
• Add Document URL
• Change Control Workflow - Collaborative Review
• Completed Change Control Workflow - Collaborative Review
• Created Check in Document after Editing
• Check Out Document for Editing
• Copy Document from Room
• Delete Attachment
• Delete Document
• Document Copied to Room
• Document Edit Mode Switched
• Edit Document Online
• Edit Document Online Accessed
• Move Document to Folder
• Metadata Update
• Export Document
• Lock Document Profile
• Mass Coding
• New Attachment
• New Document Profile
• Open Document
• Open Document Metadata
• QC Workflow - Claim Document
• QC Workflow - Exclude
• QC Workflow - Release Document
• QC Workflow - Swim Lane
• Reject Document
• Replace Attachment
• Restore Document
• Save Document
• Security Update
• Set Document Start Version
• Unlock Document Profile
• Update Default Field Value
• Update Document URL

Activity Types and Actions can be found in the dropdown lists within the audit trail filters. These filters provide a list of various document-related actions, such as “Add Document URL,” “Delete Document,” “Mass Coding,” and others.

Users were not automatically transitioned because the enhanced TI Viewer must be explicitly enabled in the room configuration for it to apply to supported document types.

This is a common misunderstanding. The viewer itself must still be enabled in the room configuration. What was “enabled by default” was an improvement to the viewer’s functionality, not the activation of the viewer for all file types.

Yes, this is expected system behavior. Documentation should clarify that the enhanced TI Viewer must be enabled in the room configuration to take effect, even though some improvements to the viewer are enabled by default.

There are three viewers with distinct functions:

• Original Viewer: Opens the file directly in the browser.
• TI Viewer (Previous Viewer): Uses ARender to convert most file types to PDF for display.
• Enhanced TI Viewer (TI Editor): Uses OnlyOffice to view (and edit) Microsoft Office files and can also function as a viewer for these file types.

Viewer selection depends on the use case:

• TI Viewer (ARender): Best for general use cases where files are converted to PDF for consistent rendering.

• Enhanced TI Viewer (TI Editor / OnlyOffice): Best suited for viewing and editing Microsoft Office files (Word, Excel, PowerPoint).
• Original Viewer (Native Browser Viewer): Ideal for files already in PDF format or for media files such as videos.

Each viewer excels at different tasks—no single viewer provides optimal performance across all file types and use cases. Maintaining multiple viewers allows users to choose the best tool for their specific document types and workflows.

While it is technically possible to set Markup and Balloons as the default display mode in OnlyOffice, there is currently no configuration available to apply this setting globally across all documents. At this time, it is only configured for specific use cases, such as CTMS visit reports.

There is no direct configuration workaround available within the current system. To request this as an enhancement, it is recommended to create an AHA ticket so the feature can be considered for future development.

Re-uploading the documents in zipped format could be a viable workaround; however, the issue should be investigated first to determine whether a broader, more sustainable solution is available.

Site Visit Documents finalized and signed in the CCR are expected to auto-file into the linked eTMF with a status of Final, bypassing Indexing and Review workflows. The current behavior—where documents are instead available for Indexing and Review—indicates a defect and does not align with the intended functionality.

It is expected behavior for ARender and Adobe not to display Word comments or tracked changes, as these viewers do not support that functionality. To view tracked changes, Microsoft Word or OnlyOffice must be used. Although Word documents were configured to render with OnlyOffice for supported file types (.doc, .docm, .docx, .dotm, .dotx), users observed that tracked changes were only visible when comments were present. Further testing showed OnlyOffice uses display modes such as Final, Original, and Markup, and may default to a mode that hides changes. Switching to “Markup and Balloons” displays tracked changes correctly.

Trial Interactive can merge files up to 3 MB per file. The following document types are supported by the Merge function:

• doc

• docx
• ppt
• pptx
• pdf

The following characters are illegal in exported filenames. Some are illegal on Windows, while others are illegal on macOS or Linux/Unix:

• # (pound) [valid on Windows only]
• % (percent)
• & (ampersand) [valid on Windows only]
• { (left curly bracket)
• } (right curly bracket)
• $ (dollar sign)
• ! (exclamation point)
• ' (single quote)
• + (plus sign)
• ` (backtick)
• = (equal sign)
• < (less than)
• > (greater than)
• : (colon)
• " (double quote)
• / (forward slash)
• \ (backslash)
• | (vertical bar / pipe)
• ? (question mark)
• * (asterisk)

The following are key terms related to documents and placeholders:

• Unfulfilled placeholders / missing: The count of placeholders required by the eTMF that are still waiting to be collected or marked final. Also referred to as missing required documents or “missing.”

• Fulfilled placeholders: The count of placeholders that have been collected, indexed, QC’d, and marked as final in the eTMF.

• Collected: The total count of final, collected documents in the eTMF. This includes fulfilled placeholders as well as additional documents and versions where more than one document fulfills a requirement. For non-TMF rooms, this metric may represent non-final documents depending on room configuration.

• Overdue: The count of unfulfilled placeholders past the due date driven by a completed event or milestone. Due dates are calculated based on the event completion date plus a configured due date period.

Some operating systems and word processing applications (for example, Microsoft Word when using “Save As”) may add non-visible data to a file. While the document appears identical when opened, these differences can result in a different hash value, allowing seemingly identical documents to be stored in the same TI room.

Some PDFs include form fields designed to be editable. These fields can still appear editable in the Original Viewer because it is the browser’s native PDF viewer and displays the document as-is. Changes made in this viewer are not saved within TI. To view the rendered output used by TI, open the document in the TI Viewer, which is the recommended option.

Once OCR and ML Automation are enabled, OCR processing runs automatically and can be configured. ML can also be used to optimize OCR behavior based on document type.

The typical flow is as follows:

• Client sends the email.
• TI email service receives the message and sends an acknowledgment.
• TI service performs virus scans, security checks, and macro analysis.
• The email is routed to the appropriate study room inbox.
• If metadata is available, the system attempts to classify the attachments.
• If routed to an email correspondence inbox, the email is made available for relevance review and converted to PDF.
• Attachments are processed by the TI OCR service.
• Optional Automate service classifies documents and extracts metadata.
• Final documents are routed to the appropriate eTMF index locations.

Note: Additional workflows exist for query-based email flows.