DOI_Routing_and_Document_Management.pdf

DOI Routing and Document Management

1. Purpose and Objective The purpose of this requirement is to explore commercial off-the-shelf (COTS) solutions for a secure, web-based Department-wide solution for routing documents for information, review, approval and concurrence. A COTS solution is desired to streamline development processes and enable rapid deployment to better meet the Department's needs and should limit customization as much as possible to an out-of-the-box solution. The proposed solution would provide an affordable, easy-to-use solution that streamlines the routing of documents to support a wide variety of missions. DOI wants to standardize, consolidate and eliminate any unnecessary duplication of products across the enterprise and ensure tools support processes versus tools driving the process. With these objectives, the tool must not only be multi-functional but also provide maximum flexibility to apply to multiple routing scenarios with little to no modification needed.

It is possible that this routing would be utilized for a limited number of routing scenarios, however, for this engagement with industry, DOI is considering how this functionality could be offered across the enterprise to be used in a wide variety of routing scenarios. Functionality supporting online/offline, mobile, multi-collaborative, and electronic / digital signatures is desired. All vendor solutions should allow users throughout the Department to create a record with attachments for routing through one or multiple steps. When the record is submitted, the routing is initiated which may then progress by selecting an established routing chain with a custom name or processed through creating routing to one individual or ad hoc selection of individuals. The defined routing workflow, where action owner(s) are assigned at each step is followed until complete. Proposed solutions should support all operational needs as well as provide functionality that provides oversight and management.

For this document, any reference to the term “record” means any document, request, memo, or other item entered in the solution for routing. A record in this scenario would include all the data and metadata associated with or required for the routing and eventual approval of a document.

Records may be requested through the Freedom of Information Act (FOIA) process and could be used in legal proceedings.

2. Background and Functionality Needed DOI has multiple document routing use cases and is currently using multiple tools to route documents for information, review, concurrence, and approval. Some of the existing tools require extensive customization and some have outdated technology. DOI is undergoing changes and population counts may adjust, however, for purposes of this RFI, the following employee counts should be considered as potential users for tool solutions: 50k-75k employees, 3 full system administrators and 30 local administrators.

Operational features of any solution must include creating, searching, and managing records for routing, adding and managing attachments, and automated notifications. Features must provide end user support knowledge documentation for use by existing DOI Tier 1 IT helpdesk agents.

The system will be utilized for official correspondence, rule-making, and cross-organizational approvals so it must meet evidentiary standards of auditability, security, and nonrepudiation.

The proposed solution should allow users to create a record for routing and associate a routing workflow to the record. Attachments or links to documents can be added to the record – one or multiple at once. Large files of varying formats and links should be supported. Users should have the capability to enter a file description, manage attachments with file versioning, and delete files they have uploaded. A suspense date for the record’s workflow should be captured for the solution to auto-calculate how many days are allocated for each step in routing.

Routing

At a high-level, routing functionality should include a pre-selected routing chain as well as a custom or a mix of the two. The routing history should include routing steps, details, and actions taken, and should be tracked and visible to those who have access to the record. Users should also be able to search for and filter records within the system to locate information easily. Routings should be capable of being parallel and/or linear and have both group assignment (queuing) and individual assignment capability at each routing/workflow step.

Visibility and permissions should be controllable within the routing workflows (e.g. the stage/step can set permissions on the record, fields within the record, and the documents associated with the record).

Routing Functionality Could Include:

- Ability to define standard, reusable routing workflows for specific routing types (e.g., Federal Register Correspondence, Secretary signature)

- Ability to modify a pre-defined standard routing workflow prior to or during the routing

- Ability to create a custom routing workflow

- Ability to use defined templates for document input, editing and collaboration purposes

- Ability to cross-pollinate data and information with other internal systems through Application

Program Interfaces (API) or Electronic Data Interchange methods

- Ability to support electronic, digital, fingerprint and facial signature or object approval

- Ability to access or interoperate with internal systems through standards-based interoperability

- Ability to support Artificial Intelligence with automated view and correspondence assessment, as well as redlining related to risk and compliance, clause generation, reference review such as alignment the Federal Code of Regulations, and Federal Acquisition Regulations (FAR) and alike

- Ability to support bulk attribute, and single or multiple summary review

- Ability for the structured and unstructured data/information solution to be intelligence searchable using Boolean, fuzzy, proximity, relevance, and like tools

- Ability to publish or feed internal dashboarding in support of Business Process Management statuses with escalation notices via eMail, Chat, or SMS

- Ability to support records, 508, and Controlled Unclassified Information

- Ability to dynamically publish work products to different internal accessible systems and externally via eMail or via other tools

- Ability to incorporate HTML based information for each process workflow items

- Ability to include field and entry, masking, remote data field lookup, data-concatenation from other systems, pull-down, quick-type, bubble, check-box, picture and cut and paste contact like features

- Ability to route a record to multiple people simultaneously for either a single individual, multiple individuals, or all individuals to perform the action before moving to the next step

- Ability to return a record for rework or return to a prior workflow step for rework and reinitiating/ following the subsequent routing steps after rework

- Ability to route records to/from external parties who do not have access to the solution

- Ability for automated email, SMS, and Instant Messaging notifications

Security and Auditability

- The solution should support industry and government FedRAMP Authorization

- Multi-layered record security including the capability for field, record, and routing security and permissions. This must include workflow-driven security.

All interactions with the system must be logged at both the system and the record level. This includes reads/access of a record. The interactions being logged must include “e.g., who, what, when, where” information and include session information as well as authenticated user ID for nonrepudiation and accountability. Logging data must be made available in timeframes, in machine readable format(s), interface with Government owned and operated appliances and apparatuses, and upon request to ensure data integrity and availability.

Oversight and Administration Functions

The solution should support the ability to designate users by required permissions and accessible records to segregate application features and record access. Users should have access to records they have submitted or have an associated action. They should be able to quickly determine assigned and upcoming actions as well as track statuses for their submitted records via dashboards. Administrators should have increased permissions to support user management and managing workflows, records and attachments within the solution.

Reporting of records, routing workflows, and attachments information should be available and separated by defined groups. Reporting should include dashboards summarizing records en route and processed and limiting based on user access and group. The solution should support the ability to set timeframe to archive records – when the record no longer displays in solution.

Notification timing (e.g. email, SMS & IM) , content including embedded links, and notification recipients should be available but customizable by DOI and by users. Other notifications, such as in-application notifications are also desired.

RFI OBJECTIVE

The purpose of this RFI is part of the acquisition planning and market research phase for acquisition related to large enterprise routing and workflow solutions and the input received from this RFI will be considered in preparing future related official acquisition packages.

The RFI is for information and planning purposes only. It is not a commitment by the Government and does not constitute a solicitation. Responses to this notice are not and cannot be accepted by the Government to form a binding contract. A Request for Proposal is not a part of this RFI, and a task order/contract will not be awarded from this announcement. No reimbursement will be made for any costs associated with providing information in response to this announcement and/or any follow-up information requested.

HOW TO RESPOND

Written Responses to the questions are due no later than July 15, 2025 @ 10:00 a.m. Eastern Time (ET). Interested parties are advised to email their responses directly to the Contracting Officer Stephanie McCullough at stephanie_mccullough@ibc.doi.gov. The Government will acknowledge receipt of your response.

Written responses should be limited to not more than 10 pages single sided. Product videos may also be submitted to demonstrate tool capability, and an upload link will be provided by the Contracting Officer if vendors choose to augment their written responses with a video.

In addition to written responses, there will be a limited number of opportunities to provide an in-person or virtual capabilities briefing that should include a product demo and responses provided to this RFI. In person briefings will be held at the Main Interior Building in Washington DC. Tentative dates for the capability briefings are July 9-25, 2025. Responses are not due until July 15, 2025, however, if responses are submitted earlier, capability briefings can be scheduled sooner.

Capability briefings won’t be held prior to submission of responses.

If you would like to schedule a capability briefing, email your request to the Contracting Officer identified above. If availability exists for the presentation, confirmation will be provided. Once the vendor receives confirmation, presenters will have 2 days to submit a high-level response, not to exceed two-pages single sided, highlighting the out of the box commercial product meeting the objectives of this RFI. If the vendor response is not received and verified, the capabilities briefing will be canceled and the time slot will be provided to another waitlisted vendor.

Capability briefings will be 2-hour time slots with 1-hour 15 minutes for vendor presentations and up to 45 minutes for the Government Team to ask questions. Vendors should limit company highlights to less than 7 minutes of the presentation and focus the briefing on responses to the questions, including full demonstration of the out of the box solution. The capabilities briefings will need to address the following questions within the timeframe specified.

1. Tool Overview and High-Level Functionality: Provide an overview of your tool capability and how it meets the requirements in this RFI to include items such as:

a. Describing key functionality including the user experience supporting quick adoption.

b. Describing a standard document routing from draft through all surnaming and approvals with automated deadline calculations and enforcement for each stage/step.

c. Providing a detailed explanation and visuals of the workflow management and routing process. This should include core requirements such as field level security, parallel and linear routing, and workflow-driven access controls.

mailto:S mailto:stephanie_mccullough@ibc.doi.gov

2. Provide details on the operating functionality of the proposed tool that could include areas such as:

a. Describing the data, metadata, and document collaboration capabilities including document versioning, records management, and embedded versus structured external data records/fields.

b. Providing a detailed explanation of the audit and evidentiary capabilities of the system that includes access and modification logging as well as the association with authenticated user activities.

c. Describing any reports, key performance indicators (KPIs), and dashboards that the system provides and what visibility controls (on reports and dashboards) are provided.

Example KPs: Time-in-status, average time at status/office/assignee, Aggregate and individual routing time-to-delivery averages.

3. Provide the timeline for implementation of the tool, including training if needed, but NOT including the ATO or any other security accreditation process (e.g. FedRAMP), as well as any success stories with other federal entities.

4. Provide details on your pricing structure, including any Tiered Pricing. For example, provide details on your solution if all DOI employees were able to utilize the tool - an all-DOI enterprise solution (50k-75k personnel). Provide details on if 25% of all employees were to utilize the tool. Request details all tiered pricing your firm offers.

5. Describe compliance capabilities of the system, specifically areas such as Section 508 of the Rehabilitation Act, FOIA, and NARA compliance capabilities.

6. If the Government determines testing industry tools is a logical next step, would your firm offer a two-week test environment where up to 30 DOI employees could test your solution to experience the full capability?