DFS REQUEST FOR INFORMATION - Amendment 1 - Final.pdf

Massachusetts DFS/MFA — Integrated Cloud-Based Software Platform Solution (AMS, LMS/TMS) RFI

Page | 1 Department of Fire Services | One State Road, Stow, MA 01775 | www.mass.gov/dfs

Commonwealth of Massachusetts The Executive Office of Public Safety and Security

The Department of Fire Services

Massachusetts Department of Fire Services (DFS) Massachusetts Firefighting Academy (MFA)

Integrated Cloud-Based Software Platform Solution (AMS, LMS/TMS)

Request for Information (RFI)

COMMBUYS Bid Number BD-27-1021-DFS-DFS01-131735

Document Control RFI Amendment 1 – removed NERIS requirement , Questions & Answers posted to COMMBUYS, & Extended final response date

Issue Date August 19, 2026 Project Manager Kenneth J. Larson, EOPSS EPS Buyer Alison Gallón, Department of Fire Services Distribution DFS Leadership, MFA Governance Committee, Prospective Respondents

Disclaimer Respondents to this Request for Information (RFI) are invited to respond to any or all of the questions or requirements stated in this document. Responses to this RFI shall serve solely to assist the Commonwealth in understanding the current state of the marketplace with regard to the solicited information or to inform the development of a possible solicitation for a Request for Responses (RFR) or Request for Quotes (RFQ) in the future. This RFI does not in any way obligate the Commonwealth to issue or amend a solicitation or to include any of the RFI provisions or responses in any solicitation. Responding to this RFI is entirely voluntary and will in no way affect the Commonwealth's consideration of any proposal submitted in response to any subsequent solicitation, nor will it serve as an advantage or disadvantage to the respondent in the course of any RFR or RFQ that may be subsequently issued or amended.

In accordance with M.G.L. c. 66 and M.G.L. c. 4, § 7 (26), this RFI and all responses hereto including the winning bid shall become public record and can be obtained from the Executive Office of Public Safety and Security by submitting a request at https://www.mass.gov/executive-office-of-technology-services-and-security-prr . Any portions of a response that are labeled as confidential will still be considered public record.

https://www.mass.gov/executive-office-of-technology-services-and-security-prr https://www.mass.gov/executive-office-of-technology-services-and-security-prr

Page | 2

1.0 INTRODUCTION

1.1 Purpose and Scope

This Request for Information ("RFI") does not commit to the Commonwealth of Massachusetts ("Commonwealth") or the Agency to pay any costs incurred in preparing a response or to purchase any products or services. The purpose of this RFI is to solicit insight and market information from knowledgeable vendors to help the Commonwealth develop a potential future solicitation for an Integrated Cloud-Based Software Platform Solution (AMS, LMS/TMS).

The solution is intended to support MFA's three campuses—Stow (primary), Springfield, and Bridgewater, as well as up to 400+ remote locations across the Commonwealth1—under Commonwealth procurement standards and an 18-month project timeline.

The MFA is sourcing a full-scale platform solution to address administration, learning, and training management system capable of supporting all activities of the Massachusetts Firefighting Academy including, but not limited to certification tracking, multi-campus scheduling, compliance reporting, workflow mapping, equipment and resource scheduling, and data management, while maintaining an independent learning and training curriculum.

No vendor has been preselected. The sourcing process will be conducted through a competitive and transparent RFI/RFR process in full compliance with Commonwealth of Massachusetts procurement regulations. The process is intended to avoid unnecessarily narrowing the vendor field, preserving competitive integrity, and maximizing the Commonwealth's ability to identify the best-fit solution for MFA's operational requirements.

Responses to this RFI should provide information that will assist the Commonwealth in drafting one or more future procurement solicitations related to the Integrated Cloud-Based Software Platform Solution (AMS, LMS/TMS).

The Agency may amend this RFI at any time before responses are due. Any amendment will be posted to the Commonwealth's procurement website, COMMBUYS.

Respondents must submit their responses through the Commonwealth's online procurement system, COMMBUYS, as detailed in Section 3. Respondents are advised to check COMMBUYS regularly, as it will be the sole method used to communicate changes. If you have never used this platform, please use the references provided to become familiar or reach out for help.

1 The 400+ Remote Locations: This aligns with the total number of municipal fire stations, districts, and call/volunteer departments distributed across The Commonwealth of Massachusetts that can request remote training from the State DFS MFA.

Page | 3

2.0 GENERAL PROCUREMENT INFORMATION

2.1 General Information

Purchasing Entity Department of Fire Services Address One State Road, Stow, MA 01775 Procurement Contact Ken Larson, PM (EoPSS EPS) Telephone 781-445-1229 E-Mail Address Kenneth.Larson@mass.gov RFI File Number and Title DFS RFI RQ- 623076 Attachments Section 3– COMMBUYS Instructions

2.2 Event Calendar

All times referenced in this RFI are Eastern Time. Responses must be received no later than the due date and time indicated below to be considered. Respondents must ensure that their submissions are fully uploaded and accepted in COMMBUYS before the RFI response deadline.

Respondents are strongly encouraged to allow sufficient time to upload their complete response.

Procurement Step Due Date Time (ET)

RFI Release Date 7/24/26

Deadline for Submission of Questions Through COMMBUYS 8/14/26 2:00PM

DFS Posted Answers for RFI Q&A (Estimated) 8/28/26

Deadline For Supplier Responses (PDF format) to RFI 9/14/26 2:00PM

2.3 General Instructions

This RFI is issued solely to gather market information. Nothing in this document constitutes a commitment by the Commonwealth to award a contract, reimburse any costs, or issue a subsequent solicitation. A non-response in COMMBUYS will remove you from further consideration. Please make sure your platform can support at least 70% or the MFA’s requirements.

Page | 4

2.3.1 Posting Date

This RFI has been posted in COMMBUYS on Release Requisition RQ-27-1021-DFS-DFS01- 623076.

2.3.2 Questions and Clarifications

Respondents may submit written questions through COMMBUYS by the deadline listed in the procurement calendar. Responses to timely questions will be provided through COMMBUYS for all interested parties.

2.3.3 Informational Session

If the Commonwealth schedules an informational session for this RFI, the date, time, and participation details will be posted in COMMBUYS. If no informational session is scheduled, respondents should rely on the written materials and published question-and-answer process.

2.3.4 Response Submission

Responses are due no later than the time and date listed in the procurement calendar. Respondents must submit a PDF format document response through COMMBUYS. The first page of the response must identify the official name of the responding entity, and all pages should be numbered sequentially.

2.3.5 Response Content

Responses should address each applicable question and requirement in the objectives and functional requirements sections of this RFI.

2.3.6 Response Format

The Commonwealth requests a point-by-point response to each numbered subsection. If a respondent does not address a particular item, the response should indicate that clearly and, where possible, explain why.

2.3.7 Additional Information

The Commonwealth may request additional information, clarifications, demonstrations, or presentations from one or more respondents. The Commonwealth may also use information gathered through this RFI to inform one or more future solicitations.

Page | 5

2.4 Miscellaneous

2.4.1 Enterprise Information Security Standards and Policies

All products and services provided to the Commonwealth must comply with applicable agency and enterprise security requirements. At a minimum, respondents should describe how their proposed solution aligns with the Commonwealth's Enterprise Information Security Standards and Policies https://www.mass.gov/handbook/enterprise-information-security-policies-and-standards

2.4.2 Accessibility Requirements for IT Solutions

The Commonwealth's Enterprise Digital Accessibility Policy requires digital assets, including third party-delivered solutions, to be accessible and usable by all people as required by state and federal law. Where a proposed solution includes digital assets, respondents should explain how the solution meets the Commonwealth's Digital Accessibility Standards.

These standards include Web Content Accessibility Guidelines (WCAG) 2.1 Levels A and AA.

Respondents should identify available accessibility documentation, including any VPAT, testing practices, and approaches used to support accessible implementation and ongoing maintenance.

During the review process and upon request, respondents should be prepared to cooperate with accessibility review activities and to provide access needed for evaluation of applicable digital products.

2.4.3 Promotional Materials

Respondents must not reference the Agency or the Commonwealth in promotional or marketing materials, including by using the Agency's or Commonwealth's name or logo, without prior written approval. Use of the Commonwealth's seal is prohibited in promotional materials.

Respondents are discouraged from including unnecessary promotional content in their RFI responses. Concise, relevant submissions are preferred.

2.4.4 Review Rights

Responses may be reviewed by Commonwealth personnel and, at the Agency's discretion, by advisors or consultants engaged to support evaluation and analysis of responses.

2.4.5 No Reimbursement

Each respondent is solely responsible for all costs associated with preparing and submitting a response to this RFI. The Commonwealth will not reimburse any such costs.

https://www.mass.gov/handbook/enterprise-information-security-policies-and-standards

Page | 6

2.4.6 Generative AI Policy

Respondents should identify any material use of generative AI relevant to the proposed solution and should be prepared to comply with applicable Commonwealth policy requirements, including the Enterprise Use and Development of Generative Artificial Intelligence Policy http://www.mass.gov/doc/enterprise-use-and-development-of-generative-artificial-intelligence-policy/download

3.0 COMMBUYS INSTRUCTIONS

3.1 Submission Requirements

Interested respondents must submit their response through COMMBUYS. If you have never used this service of the Commonwealth, Please visit, https://www.mass.gov/info-details/completing-vendor-registration-in-commbuys or contact the help desk (see below).

Bidders may contact the Commonwealth’s Operations Services Division Help Desk at OSDHelpDesk@mass.gov or call during normal business hours (8AM – 5PM, Monday – Friday) at 1-888-627-8283 or 617-720-3197. You can visit the Job Aids and Vendor training page at https://www.mass.gov/osd-vendor-training

3.1.1 Job Aid Reference

A job aid on how to submit a question is available at: https://www.mass.gov/lists/job-aids-for-vendors-using-commbuys

3.1.2 Webcast Reference

A webcast titled "How to Locate and Respond to a Bid in COMMBUYS" is available and will familiarize bidders with COMMBUYS terminology, basic navigation, and provide guidance for locating bid opportunities in COMMBUYS and submitting an online quote.

Respondents must ensure that their complete submission is uploaded and successfully submitted before the date and time listed in the procurement calendar. COMMBUYS will not accept late submissions.

http://www.mass.gov/doc/enterprise-use-and-development-of-generative-artificial-intelligence-policy/download http://www.mass.gov/doc/enterprise-use-and-development-of-generative-artificial-intelligence-policy/download https://www.mass.gov/info-details/completing-vendor-registration-in-commbuys https://www.mass.gov/info-details/completing-vendor-registration-in-commbuys mailto:OSDHelpDesk@mass.gov https://www.mass.gov/osd-vendor-training https://www.mass.gov/lists/job-aids-for-vendors-using-commbuys https://www.mass.gov/lists/job-aids-for-vendors-using-commbuys

Page | 7

3.2 Written Questions Through COMMBUYS

The "Bid Q&A" feature allows respondents to submit written questions and receive written answers regarding this RFI. All questions must be submitted through the Bid Q&A feature in COMMBUYS before the deadline listed in the procurement calendar. The issuing department reserves the right not to respond to questions submitted after that deadline. Respondents are responsible for confirming that their questions were successfully submitted.

Questions submitted through other channels, including mail, fax, email, or voicemail, will not be answered. To reduce duplication, respondents should review previously submitted questions before submitting a new question.

Questions entered into COMMBUYS must be suitable for public viewing. Respondents must not include personal information, security-sensitive information, collusive content, or other objectionable material. The Commonwealth reserves the right to edit or remove submitted questions that are inappropriate or not in the best interest of the procurement process.

All answers are final when posted. Any subsequent revisions to previously provided answers will be dated.

Prospective respondents are responsible for maintaining an active COMMBUYS registration, keeping contact information current, and monitoring the email address associated with their COMMBUYS account for procurement communications and clarification requests. The Commonwealth is not responsible for missed communications caused by outdated contact information or technical issues affecting the respondent's systems or internet service.

3.3 Locating the Bid Q&A Feature

In COMMBUYS, locate the bid, acknowledge receipt if required, and navigate to the bid header page. The "Bid Q&A" feature is available near the bottom of that page.

4.0 RESPONDENT INFORMATION AND SUBMISSION MATERIALS

4.1 Respondent Profile

Respondents should provide the organizational and contact information below as part of their response package.

Page | 8

Title Respondent Response

Legal Business Name

Headquarters Location

Years in Business

Number of Employees

Primary Product Name & Version

Cloud Hosting Model

Experience with Public Safety / Government

Largest Deployment (User Count)

4.2 Response Cover Letter

Include a brief cover letter signed by an authorized representative that identifies the responding entity, confirms the primary response contact, and summarizes the respondent's qualifications and interest in this RFI. The cover letter may reference the respondent profile information already provided rather than repeating it in full.

5.0 RESPONDENT RESPONSE TOPICS

5.1 Technical Solution Overview

Respondents should address each of the following topics as part of their technical narrative.

5.1.1 Software, Platform Components, and Supporting Hardware

Describe the software, platform components, and any supporting hardware required to deliver the proposed solution.

5.1.2 Implementation and Advisory Services

Describe the implementation, configuration, integration, migration, training, and advisory services recommended for a successful deployment.

Page | 9

5.1.3 Digital Accessibility Alignment

Explain how the proposed solution aligns with the Commonwealth's digital accessibility standards and describe the basis for that assessment.

5.1.4 Current and Recent Implementations

Provide examples of current or recent implementations of the proposed solution, including relevant sectors, use cases, and any key implementation partners.

5.1.5 Comparable Projects and Lessons Learned

Describe comparable projects completed successfully and identify the critical success factors, lessons learned, and implementation risks.

5.1.6 Third-Party Products and External Dependencies

Identify any third-party products, subcontractors, hosting arrangements, or external dependencies that are material to the proposed solution.

5.2 Commercial and Support Information

5.2.1 Cost Information

Respondents should provide a high-level breakdown of implementation-related cost categories.

The following items should be addressed:

5.2.1.1 Cost Category Breakdown. Provide a high-level breakdown of implementation-related cost categories, such as software, services, configuration, integration, data migration, training, and any required third-party components.

5.2.1.2 Pricing Model Considerations. Describe any pricing model considerations relevant to scale, such as enterprise licensing, volume tiers, or statewide adoption scenarios. (This is not a pricing request. Vendors should provide the following high-level cost model information to assist the Commonwealth in understanding the general commercial structure of the proposed solution)

5.2.1.3 Standard Commercial Documents. Identify standard commercial documents typically associated with the solution, such as licensing, subscription, or support terms, if available for later review.

Page | 10

5.2.2 Training and Enablement

Respondents should address the following items regarding training and enablement:

5.2.2.1 Training Inclusion. Indicate whether administrator, instructor, and technical training are included or offered separately.

5.2.2.2 Training Formats. List the training formats available, such as instructor-led, self-paced, train-the-trainer, or role-based training.

5.2.2.3 Duration and Delivery. Describe the typical duration, delivery method, and timing of training activities.

5.2.2.4 Documentation and Training Materials. Describe the documentation, knowledge articles, or training materials made available to support adoption.

5.2.3 Support and Maintenance

Respondents should address the following items regarding support and maintenance:

5.2.3.1 Support Hours and Channels. Describe support hours, channels, and any tiered service options.

5.2.3.2 Response and Resolution Commitments. Describe standard response and resolution commitments, if available.

5.2.3.3 Support Delivery Location. Identify where support services are delivered from and whether support is provided directly or through partners.

5.2.3.4 Updates, Patches, and Bug Fixes. Explain how updates, patches, and bug fixes are delivered and whether they are included in standard support arrangements.

5.2.3.5 Escalation Process. Describe the escalation process for incidents and service issues.

5.2.3.6 Multi-Campus Support. Explain how support is provided for multiple campuses, sites, or installations within a single customer environment.

5.2.3.7 Major Releases and Enhanced Feature Sets. Describe how major releases, optional upgrades, or enhanced feature sets are handled commercially.

5.2.3.8 Standard Support Terms. Identify any standard support or maintenance terms that may be available for later review.

Page | 11

5.2.4 Customization and Contracting Context

Respondents may also identify whether the proposed solution can be configured or customized, any major considerations associated with such work, and whether the organization currently participates in relevant Commonwealth statewide contracts.

6.0 HIGH-LEVEL REQUIREMENTS WEIGHTING

The weighting below reflects the Commonwealth's current priorities for this initiative.

Respondents should use these weightings to help focus their responses on the most important capabilities, implementation considerations, and differentiators.

Section Capability Category Weight

6.1 Academy Management Administration Readiness 14%

6.2 Workflow Enablement Capability 14%

6.3 Multi-Campus Operation (Different Sites) 14%

6.4 Supplier Solution Components (AMS/LMS/TMS) 14%

6.5 Curriculum Independence 10%

6.6 Supplier Financial Stability 10%

6.7 Ongoing Support Services and Training Platform 9%

6.8 Low Implementation Complexity 5%

6.9 Consulting Resources for Onboarding 5%

6.10 Public Safety Domain and State Adoption 5%

TOTAL 100%

6.1 Academy Management Administration Readiness — 14%

This criterion assesses the vendor's ability to support end-to-end academy operations out of the box. Included in this evaluation are the maturity of features such as class scheduling, rosters, instructor assignment, certification workflows, facility management, and administrative controls.

This criterion measures whether the solution is operationally ready for a public-safety training academy with minimal customization.

Page | 12

6.2 Workflow Enablement Capability — 14%

This criterion evaluates the platform's ability to help automate manual processes across the training lifecycle. Included in this evaluation are configurable workflows, approval routing, automated notifications, compliance triggers, task sequencing, and reduction of administrative burden.. We will need to understand specifically how the software utilizes AI and that it is following the commonwealth’s policy.2

6.3 Multi-Campus Operation (Different Sites) 14%

This criterion measures the system's ability to support multiple training locations under a unified administrative structure. Included in this evaluation are site-level permissions, decentralized scheduling, localized reporting, resource allocation, and cross-campus coordination. Priority is given to solutions that can scale across regional academies, satellite sites, and statewide deployments.

6.4 Supplier Solution Components (AMS/LMS/TMS) 14%

This criterion evaluates whether the vendor provides a complete, integrated solution that includes the following components:

6.4.1 AMS (Academy Management System). This component encompasses administrative operations, rosters, scheduling, and certifications.

6.4.2 LMS (Learning Management System). This component encompasses online learning, assessments, content delivery, and tracking.

6.4.3 TMS (Training Management System). The component encompasses operational planning at the academy and larger scale department level operational planning, resource management, instructor and staff utilization, and compliance reporting.

Higher scores reflect native inclusion of all three components or proven data Integration and export capabilities that deliver a seamless end-to-end training ecosystem.

6.5 Curriculum Independence — 10%

This criterion assesses whether the platform supports agency-defined curricula without requiring vendor-owned or proprietary content. Included in this evaluation are the flexibility to create, 2 https://www.mass.gov/artificial-intelligence-at-the-commonwealth https://www.mass.gov/artificial-intelligence-at-the-commonwealth

Page | 13 modify, and manage custom courses, lesson plans, and certification pathways. Priority is given to systems that do not lock agencies into vendor content ecosystems.

6.6 Supplier Financial Stability — 10%

This criterion evaluates the vendor's financial health, longevity, and ability to support a multi-year statewide contract. Included in this evaluation are revenue stability, funding sources, market presence, and risk of business disruption. Higher scores reflect low-risk, sustainable vendors with proven track records.

6.7 Ongoing Support Services and Training Platform — 9%

This criterion evaluates the vendor's long-term support model, including help desk responsiveness, SLAs, customer success programs, training resources, and knowledge bases. This criterion measures the sustainability and quality of post-implementation support.

6.8 Low Implementation Complexity — 5%

This criterion measures the anticipated ease of deployment, including configuration effort, data migration, onboarding time, and reliance on vendor resources. The Commonwealth prioritizes solutions that can be implemented quickly, predictably, and with minimal operational disruption.

6.9 Consulting Resources for Onboarding — 5%

This criterion assesses the availability and quality of vendor-provided implementation specialists, project managers, technical consultants, and training staff. Included in this evaluation are methodology, staffing levels, onboarding tools, and the ability to support a structured rollout.

6.10 Public Safety Domain and State Adoption — 5%

This criterion measures the extent to which the solution is already adopted by other state agencies or statewide training programs, demonstrating proven scalability, compliance alignment, and familiarity with state-level reporting and governance. This criterion also evaluates the vendor's experience serving police, fire, EMS, corrections, and other public-safety organizations, and includes domain expertise, regulatory understanding, and the ability to support mission-critical training environments.

Page | 14

7.0 FUNCTIONAL REQUIREMENTS

Respondents should describe how their platform supports the capabilities below. Narrative responses are preferred. Where helpful, respondents may include references to standard product functionality, optional modules, configuration approaches, integrations, implementation assumptions, and known limitations.

7.1 User Experience and Accessibility

7.1.1 Multi-Lingual Support

Respondents should describe multi-lingual support capabilities, addressing the following items:

7.1.1.1 Supported UI Languages. Respondents should identify all user interface languages currently supported by the platform, including both standard and optional language packs.

7.1.1.2 Translation Scope. Respondents should describe whether admin tools, notifications, registration workflows, and help content are fully translated in supported languages or whether translation is limited to learner-facing content only.

7.1.1.3 Custom Field and Metadata Translation. Respondents should describe the platform's ability to translate custom fields, banners, and metadata into supported languages.

7.1.1.4 Course Language Tagging and Filtering. Respondents should describe how course language is tagged and made filterable by learners searching for content in a preferred language.

7.1.2 Accessibility

Respondents should describe platform accessibility capabilities, addressing the following items:

7.1.2.1 WCAG 2.1 AA and Section 508 Compliance. Respondents should confirm whether the platform is compliant with WCAG 2.1 Level AA and Section 508 of the Rehabilitation Act and describe the basis for that compliance assertion, including any third-party audits or certifications.

7.1.2.2 Screen Reader and Assistive Technology Support. Respondents should describe support for screen readers and other assistive technologies, including JAWS, NVDA, and Voice-over, and indicate whether the platform has been tested with such tools.

Page | 15

7.1.2.3 Mobile Responsiveness and Mobile App Availability. Respondents should describe mobile responsiveness of the web interface and confirm whether a native mobile application is available for iOS and Android.

7.1.2.4 Browser Compatibility. Respondents should describe compatibility with current versions of Chrome, Edge, Firefox, and Safari.

7.1.3 User Self-Service

Respondents should describe user self-service capabilities, addressing the following items:

7.1.3.1 Account Creation and Updates. Respondents should describe the process by which users can create and update their own accounts, including any validation or approval workflows that may be in place.

7.1.3.2 Password Reset. Respondents should describe the self-service password reset process, including multi-factor authentication considerations and integration with identity providers.

7.1.3.3 Duplicate Account Prevention. Respondents should describe how the platform detects and prevents duplicate account creation at the point of registration.

7.1.3.4 User Help Workflows. Respondents should describe built-in user help workflows and indicate whether the platform supports integration with ITSM platforms such as ServiceNow for issue tracking and resolution.

7.2 Communications and Notifications

7.2.1 Manual Communications

Respondents should describe capabilities for manual communications, addressing the following items:

7.2.1.1 Email and SMS Messaging to User Groups. Respondents should describe the platform's ability to compose and transmit targeted email and SMS messages to defined user groups, cohorts, or populations.

7.2.1.2 Instructor-to-Student Messaging. Respondents should describe tools available to instructors for direct or broadcast communication with enrolled students.

7.2.1.3 User-to-User Communication. Respondents should describe whether the platform supports peer-to-peer messaging, discussion forums, or integrated chat functionality.

Page | 16

7.2.1.4 Language-Specific Communications. Respondents should describe the platform's ability to deliver communications in a user's preferred language or in accordance with language-specific notification templates.

7.2.1.5 Large-Scale Notification Capacity. Respondents should confirm the platform's technical capacity to deliver notifications up 13,0003 or more recipients, including any known limitations, delivery queue management, or throttling mechanisms.

7.2.2 Automated Communications

Respondents should describe automated communication triggers, addressing the following items:

7.2.2.1 Enrollment Confirmations. Respondents should describe how the platform automatically generates and delivers enrollment confirmation communications to registered learners.

7.2.2.2 Waitlist Notifications. Respondents should describe how the platform notifies users when a seat becomes available from a waitlist and how priority is determined.

7.2.2.3 Course Completion Notifications. Respondents should describe how the platform notifies learners, supervisors, and administrators upon successful course completion.

7.2.2.4 Due Date Reminders. Respondents should describe the platform's capability to send configurable reminders when course or compliance deadlines are approaching.

7.2.2.5 Event Reminders. Respondents should describe automated reminders issued prior to scheduled instructor-led training events, including configurable lead times.

7.2.2.6 Cancellation Notifications. Respondents should describe how the platform handles automated notification of course or session cancellation to affected registrants.

7.2.2.7 Multi-Language Template Support. Respondents should describe whether automated notification templates can be configured for multiple languages and how the appropriate template is selected per recipient.

7.3 Course and Program Management

7.3.1 Course Types

Respondents should describe support for the following course delivery formats:

3 The MFA trains roughly 13,000 active fire service professionals annually across career recruit and continuing education programs.

https://www.youtube.com/watch?v=oL55Kt50w44

Page | 17

7.3.1.1 Instructor-Led Training. Respondents should confirm support for both in-person and virtual instructor-led training formats and describe the administrative tools available for each.

7.3.1.2 Self-Paced Learning. Respondents should describe the platform's support for asynchronous, self-paced learning modalities and the content types supported in that mode.

7.3.1.3 Blended Learning. Respondents should describe the platform's ability to combine synchronous instructor-led components with asynchronous self-paced content within a single course or program.

7.3.1.4 Microlearning. Respondents should describe support for short-format, targeted learning content, including how microlearning modules are cataloged, assigned, and tracked.

7.3.2 Content Standards

Respondents should confirm support for the following content standards and formats:

7.3.2.1 SCORM 1.2 and SCORM 2004. Respondents should confirm native support for SCORM 1.2 and SCORM 2004 packages and describe any known limitations or compatibility considerations.

7.3.2.2 xAPI / TinCan. Respondents should confirm support for the xAPI (Tin Can) specification, including whether the platform maintains an integrated Learning Record Store (LRS) or relies on an external LRS.

7.3.2.3 Video Uploads. Respondents should describe support for video content uploads, including supported formats, file size limits, streaming capabilities, and accessibility features such as captioning.

7.3.2.4 PowerPoint (PPT) Uploads. Respondents should describe the platform's ability to ingest and present PowerPoint files as course content, including any conversion or rendering mechanisms.

7.3.2.5 Assignments. Respondents should describe support for file-based or task-based assignments, including submission tracking, grading, and feedback workflows.

7.3.2.6 Quizzes and Surveys. Respondents should describe the platform's quiz and survey creation tools, including question types, scoring, randomization, passing thresholds, and survey anonymity options.

7.3.3 Instructor-Led Training

Respondents should describe instructor-led training capabilities, addressing the following items:

Page | 18

7.3.3.1 Multi-Session Scheduling. Respondents should describe the ability to schedule instructor-led training across multiple sessions or days and manage session-level enrollment and attendance.

7.3.3.2 Resource Management. Respondents should describe the platform's ability to schedule and manage rooms, instructors, and equipment in connection with instructor-led training events.

7.3.3.3 Attendance Tracking. Respondents should describe how attendance is captured for instructor-led sessions, including support for partial attendance, late arrivals, and instructor-side tools.

7.3.3.4 Webinar Integration. Respondents should describe integration capabilities with virtual meeting and webinar platforms including Zoom, Microsoft Teams, and Cisco WebEx, including automated link generation, attendance sync, and completion recording.

7.3.3.5 Waitlist Management. Respondents should describe the platform's waitlist functionality, including automated promotion, capacity enforcement, and learner notification upon seat availability.

7.3.4 Course Actions

Respondents should describe course administration capabilities, addressing the following items:

7.3.4.1 Course Copying. Respondents should describe the ability to duplicate an existing course, including settings, content, and associated resources, for reuse or modification.

7.3.4.2 Versioning. Respondents should describe how course versioning is managed, including how learner completion records are handled when a course is revised.

7.3.4.3 Archiving. Respondents should describe how courses are retired or archived when they are no longer active and how historical completion records are preserved.

7.3.4.4 Scheduled Releases. Respondents should describe the ability to schedule a course to become available to learners at a future date and time without manual intervention.

7.3.4.5 Centralized File Repository. Respondents should describe any centralized asset or file management repository within the platform for storing and reusing course-related media and documents.

7.3.5 Certificates

Respondents should describe certificate customization capabilities, including the ability to design branded completion certificates, configure issuance triggers, manage expiration dates, and provide

Page | 19 downloadable or shareable certificate formats. Respondents should also indicate whether certificate templates can be customized per course, program, or certification pathway.

7.3.6 Remote Locations and Multi-Campus Operations (DFS-Specific)

Vendors must describe how their system supports the following multi-campus and remote-location requirements, which are critical to the operational needs of the Massachusetts Firefighting Academy:

7.3.6.1 Multiple Campuses with Independent Schedules. Respondents should describe how the system supports separate, independently managed training schedules across the Stow, Springfield, and Bridgewater campuses and remote locations, while maintaining a unified administrative overview.

7.3.6.2 Shared Instructors Across Campuses. Respondents should describe how the platform manages instructor scheduling and assignment across multiple campuses, including conflict detection and availability management.

7.3.6.3 Campus-Specific Resource Pools. Respondents should describe how the platform manages campus-specific inventories of rooms, equipment, and other training resources, preventing cross-campus conflicts.

7.3.6.4 Cross-Campus Enrollment. Respondents should describe how learners can enroll in sessions offered at a campus other than their home campus, including any approval or administrative workflows involved.

7.3.6.5 Campus-Level Reporting and Dashboards. Respondents should describe campus-specific reporting views and dashboards available to local administrators, along with enterprise-wide reporting capabilities for central administration.

7.4 Certification, Credentialing, and Compliance

Respondents should describe capabilities for the following certification and compliance functions:

7.4.1 Certification Tracking

Respondents should describe how the platform tracks professional certifications earned through MFA courses and programs, including the ability to link certifications to specific completion records, manage multiple active certifications per learner, and support public-safety credentialing requirements.

Page | 20

7.4.2 Continuing Education Unit (CEU) Tracking

Respondents should describe how the platform tracks continuing education units, including CEU accumulation over time, reporting of CEU totals per learner, and alignment with accreditation or regulatory reporting requirements.

7.4.3 Expiration Alerts

Respondents should describe how the platform identifies and communicates upcoming certification or credential expirations to learners, supervisors, and administrators, including configurable alert lead times and escalation paths.

7.4.4 Recertification Workflows

Respondents should describe how the platform supports structured recertification workflows, including automated assignment of recertification requirements when credentials approach expiration and tracking of recertification completion.

7.4.5 External Testing Integrations

Respondents should describe the platform's ability to integrate with external testing or credentialing authorities, including data exchange for examination results and automated credential issuance upon passing outcomes.

7.4.6 Public Safety Credentialing Models

Respondents should describe any pre-built or configurable credentialing frameworks designed for public safety disciplines, including fire service, EMS, law enforcement, and emergency management, and experience supporting state-level credentialing systems in those domains.

7.5 Equipment and Resource Management

Respondents should describe capabilities for the following equipment and resource management functions:

7.5.1 Classroom and Equipment Scheduling

Respondents should describe how classrooms, training facilities, and physical equipment are cataloged and scheduled within the platform, including the relationship between resource scheduling and course session creation.

Page | 21

7.5.2 Conflict Detection

Respondents should describe the platform's ability to automatically detect and prevent scheduling conflicts for shared resources, including rooms, instructors, and equipment across campuses and time periods.

7.5.3 Future Reservations

Respondents should describe the ability to place advance reservations on resources for planning purposes and how those reservations are managed relative to confirmed session bookings.

7.5.4 Unique Asset IDs

Respondents should describe whether the platform supports assignment of unique identifiers to individual assets and equipment items and how those identifiers are used to track usage, maintenance cycles, or location history.

7.5.5 Integration with Equipment Management Systems

Respondents should describe available integration capabilities with external asset and equipment management systems, including the nature of the integration (real-time, batch), supported data exchanges, and any prior implementations of such integrations.

7.6 Administration and Governance

7.6.1 User Profiles and Permissions

Respondents should describe user profile and permissions capabilities, addressing the following items:

7.6.1.1 Custom Profile Fields. Respondents should describe the platform's ability to define and manage custom user profile fields, including field types, visibility controls, and whether fields can be made mandatory or optional by role.

7.6.1.2 Role-Based Permissions. Respondents should describe the role-based access control framework, including the granularity of permissions, the ability to create custom roles, and role inheritance models if applicable.

7.6.1.3 Temporary Access. Respondents should describe the platform's ability to grant time-limited access to specific content, administrative functions, or system areas for temporary users, contractors, or guest instructors.

Page | 22

7.6.1.4 Content-Level Access Restrictions. Respondents should describe the ability to restrict access to specific courses, programs, or learning paths based on role, group membership, campus affiliation, or other user attributes.

7.6.1.5 User Impersonation for Support Purposes. Respondents should describe whether administrators can impersonate user accounts for troubleshooting and support purposes and describe the audit trail generated by such actions.

7.6.1.6 Duplicate Account Merge. Respondents should describe the platform's tools for identifying and merging duplicate user accounts, including how learning history is consolidated during the merge process.

7.6.2 Integrations

Respondents should describe available APIs for the following integration types:

7.6.2.1 User Provisioning. Respondents should describe APIs or SCIM support available for automated user provisioning, de-provisioning, and profile synchronization with external identity providers or HR systems.

7.6.2.2 Course Metadata. Respondents should describe APIs available for exchanging course metadata with external catalogs, portals, or systems of record.

7.6.2.3 Learning History. Respondents should describe APIs or export mechanisms available to transfer completion records, transcripts, and learning history data to external systems.

7.6.2.4 Reporting. Respondents should describe API access to reporting data and any support for real-time or near-real-time data feeds for external analytics platforms.

7.6.2.5 Single Sign-On (SAML/OIDC). Respondents should describe support for SAML 2.0 and OpenID Connect (OIDC) for enterprise single sign-on, including experience integrating with Microsoft Azure Active Directory and other identity providers used in government environments.

7.6.3 Reporting and Analytics

Respondents should describe reporting and analytics capabilities, addressing the following items:

7.6.3.1 Built-In Reports. Respondents should identify the standard reports included with the platform, including enrollment reports, completion reports, compliance dashboards, and certification status reports relevant to a public-safety training organization.

Page | 23

7.6.3.2 Custom Report Builder. Respondents should describe any self-service custom report builder, including the data elements available, filter and grouping options, and whether reports can be saved and shared across the organization.

7.6.3.3 Scheduled Reports. Respondents should describe the ability to schedule reports for automatic generation and delivery to designated recipients on a recurring basis.

7.6.3.4 Export Formats. Respondents should confirm support for exporting report data in common formats including CSV and XLSX and identify any additional export formats available.

7.6.3.5 Power BI Integration. Respondents should describe available connectivity options for Microsoft Power BI, including direct query, API access, data connectors, or pre-built dashboards.

7.6.3.6 Site Analytics. Respondents should describe built-in site analytics, including visibility into traffic volumes, device types, browser usage, and geographic access patterns.

7.6.3.7 User Activity Logs. Respondents should describe the granularity and retention period of user activity logs and the tools available to administrators for querying and reviewing that activity.

7.6.3.8 Administrator Activity Logs. Respondents should describe audit logging of administrator actions, including the events captured, the retention period, and whether logs are tamper-resistant or exportable.

7.6.4 Implementation and Migration

Vendors must describe the following implementation and migration capabilities:

7.6.4.1 Implementation Methodology. Respondents should describe the standard project delivery methodology used for platform implementations, including phases, milestones, governance structure, and stakeholder engagement approach.

7.6.4.2 Typical Timeline for a Three-Campus Deployment. Respondents should provide a representative implementation timeline for a deployment comparable in scope to MFA's three-campus environment, including key dependencies and assumptions underlying that estimate.

7.6.4.3 Data Migration Approach. Respondents should describe the approach to data migration, specifically including the strategy for migrating legacy training records spanning from 1968 to the present, and address data cleansing, transformation, validation, and historical record preservation.

7.6.4.4 Integration Development Process. Respondents should describe the process for scoping, designing, building, and testing custom integrations as part of the implementation engagement.

Page | 24

7.6.4.5 User Acceptance Testing (UAT) Support. Respondents should describe the resources, tools, and documentation provided to support a structured User Acceptance Testing process prior to go-live.

7.6.4.6 Training and Train-the-Trainer Programs. Respondents should describe the training programs offered for end users, administrators, and trainers, including the train-the-trainer model and any certification available to internal platform administrators.

7.6.4.7 Change Management Support. Respondents should describe resources, tools, or advisory services available to support organizational change management activities, including communications planning, stakeholder engagement, and adoption monitoring.

7.6.5 Support Model

Respondents should describe their support model, addressing the following items:

7.6.5.1 Support Channels. Respondents should describe the support channels available to customers, including chat, email, and telephone, and whether access to all channels is included in standard support tiers.

7.6.5.2 Hours of Operation. Respondents should describe standard support hours, including time zones covered, and identify any extended or 24/7 support options available.

7.6.5.3 Emergency Support. Respondents should describe the process and contacts for emergencies or after-hours support for critical system failures.

7.6.5.4 Service Level Agreements (SLAs). Respondents should describe standard SLA commitments for Priority 1 through Priority 4 incidents, including initial response, acknowledgement, and resolution targets.

7.6.5.5 Update Cycle and Release Notes. Respondents should describe the platform release cadence, including how updates are communicated, how release notes are delivered, and whether customers are given advance notice and testing windows before updates are applied to production environments.

7.6.5.6 Knowledgebase and User Community Resources. Respondents should describe the self-service knowledgebase, online documentation, and user community resources available to support ongoing platform use and administrator development.

7.6.6 Security, Privacy, and Accessibility Compliance

Respondents should describe the following security, privacy, and accessibility compliance capabilities:

Page | 25

7.6.6.1 WCAG 2.1 AA Compliance. Respondents should confirm current conformance status with WCAG 2.1 Level AA and describe the most recent accessibility audit or evaluation performed.

7.6.6.2 Voluntary Product Accessibility Template (VPAT). Respondents should confirm whether a current VPAT is available and indicate the WCAG or Section 508 version against which it was prepared. Respondents should be prepared to provide a copy upon request.

7.6.6.3 Data Privacy Compliance. Respondents should describe how the platform and the vendor's data practices comply with Massachusetts General Laws Chapter 93H governing the security of personal information, as well as any applicable federal data privacy standards relevant to public-sector deployments.

7.6.6.4 Audit Logging. Respondents should describe the audit logging framework, including the events captured, log storage duration, tamper resistance, and tools for querying and exporting audit records.

7.6.6.5 Backup and Disaster Recovery. Respondents should describe the platform's backup frequency, geographic redundancy, Recovery Time Objective (RTO), and Recovery Point Objective (RPO) commitments, and describe prior disaster recovery activations if applicable.

7.6.6.6 Data Retention Policies. Respondents should describe the platform's configurable data retention policies, including how long user records, completion records, and audit logs are retained and how retention periods can be customized to meet Commonwealth requirements.

7.6.6.7 Ability to Prevent User-Initiated Data Deletion. Respondents should describe administrative controls available to prevent users from deleting their own learning records, completion history, or account data, and indicate whether such controls can be enforced at a policy level.

7.6.7 Payment Capabilities

Respondents should describe the following payment capabilities:

7.6.7.1 DFS-Managed Payments. Respondents should describe the platform's ability to support DFS-managed payment processing for course registrations, including invoicing, payment confirmation, and financial reporting.

7.6.7.2 Third-Party Provider Payments. Respondents should describe support for processing payments through third-party payment providers and identify which providers are currently supported or integrated.

Page | 26

7.6.7.3 Discount Code Support. Respondents should describe the platform's ability to create, distribute, and track promotional or discount codes for course registrations, including single-use, multi-use, and…