City_of_Cleveland_HCM_Selection_RFP_-_Attachment_B.xlsx

XLSX spreadsheet 203 KB Posted Nov 28, 2023

Attached to: Provision of a Software System and Related Professional Services for the Implementation of a Human Capital Management and HR Information System (HRIS)
Solicitation number: 2023-RFP-020
Issued by: Cuyahoga County, Ohio

About this file

Written by GovTribe AI · May 11, 2025

This document is a detailed Request for Proposal (RFP) from the City of Cleveland, Ohio, seeking a comprehensive Human Capital Management (HCM) and Human Resources Information System (HRIS) software solution. The RFP includes 14 comprehensive functional and technical requirement tabs covering areas such as General and Technical Requirements, Data Conversion, Interfaces, Advanced Scheduling, Applicant Tracking, Benefits Administration, Compensation Management, Employee Relations, HR Personnel Management, Learning Management and Performance Reviews, Payroll, Risk Management, Succession Planning, and Time and Attendance. The document provides an extensive list of critical system requirements, with vendors expected to respond to each requirement using standard indicators (Standard, Future, Customization, Third Party, or No) and provide comments or explanations.

The RFP seeks a fully integrated software system that will replace the City's current disparate systems, with data conversion requirements from multiple existing platforms including ADP, NEOGOV, BizLibrary, IAPRO BlueTeam, Telestaff, and Kronos. The system must support approximately 7,000-7,500 active employees and 14,000 inactive employees, with robust capabilities across HR functions including comprehensive reporting, workflow automation, employee self-service, and compliance with federal, state, and local regulations. While specific budget details are not explicitly stated in the attached document, the comprehensive nature of the requirements suggests a significant enterprise-level technology investment aimed at modernizing the City of Cleveland's human resources technology infrastructure.

View the file

Other files

File	Type	Posted
Provision_of_a_Software_System_and_Related_Professional_Services_for_the_Implementation_of_a_Human_Capital_Management_and_HR_Information_System_(HRIS)_(Addendum_#1_Revision).pdf	PDF	Dec 22, 2023
City_of_Cleveland_HCM_Selection_RFP_-_Specifications_Scope.docx	DOCX document	Nov 28, 2023
City_of_Cleveland_HCM_Selection_RFP_-_Attachment_C.xlsx	XLSX spreadsheet	Nov 28, 2023
City_of_Cleveland_HCM_Selection_RFP_-_Attachment_A.docx	DOCX document	Nov 28, 2023
Security_Questionnaire.docx	DOCX document	Nov 27, 2023

On GovTribe

Work with this file

Download the original file
Contacts named in this file
Similar government files
Ask GovTribe AI about this file

Try for free Login

Text version

The file's text, extracted by GovTribe without its formatting.

TOC

Table of Contents
Tab No.		Number of Requirements
Technical
1	General and Technical	78
2	Data Conversion	14
3	Interfaces	16
Functional
4	Advanced Scheduling	110
5	Applicant Tracking/Recruiting	280
6	Benefit Administration and Unemployment	202
7	Compensation Management	173
8	Employee Relations	88
9	HR Personnel Management	299
10	Learning Management and Performance Reviews	182
11	Payroll	298
12	Risk Management	57
13	Succession Planning	27
14	Time and Attendance	225
	Total Functional Requirements:	2,049

Indicator	Definition	Instruction
S	Standard: Feature/Function is included in the current software release and will be implemented by the planned phase go-live date as part of the proposal from Vendors in accordance with agreed-upon configuration planning with the City.	Proposers are encouraged, but not required, to provide additional information in the Comments column to further demonstrate the system’s ability to meet the requirement.
F	Future: Feature/Function will be available in a future software release available to the City by July 1, 2024, at which point it will be implemented in accordance with agreed-upon configuration planning with the City.	If a response indicator of “F” is provided for a requirement that will be met in a future software release, the Proposer shall indicate the planned release version, as well as the time the release will be generally available.
C	Customization: Feature/Function is not included in the current software release and is not planned to be a part of a future software release. However, this feature could be provided with custom modifications. All related customization costs should be indicated in Attachment C – Cost Worksheet.	If a response indicator of “C” is provided for a requirement that will be met through a custom modification, the Proposer shall indicate the cost of such a modification.
T	Third Party: Feature/Function is not included in the current software release and is not planned to be a part of a future software release. However, this feature could be provided with integration with a third-party system. This system should be specified.	If a response indicator of “T” is provided for a requirement that will be met by integration with a third-party system, the Proposer shall identify this third-party system and include a cost proposal to secure this system. If the third-party system is a part of the proposal, the third-party shall respond to the appropriate requirements using the “S”/”C”/”T”/”N” response indicators with a clear notation that the responses are provided by the third-party.
N	No: Feature/Function cannot be provided.	N/A

&"Arial,Bold"&14City of Cleveland &"Arial,Regular"&11List of Functional and Technical Requirements

&"Arial,Regular"&10Attachment B &"Arial,Regular"&10Page &P of &N &"Arial,Regular"&10Last Updated: November 28, 2023

1. General and Technical

Indicator	Definition	Instruction
S	Standard: Feature/Function is included in the current software release and will be implemented by the planned phase go-live date as part of the proposal from Vendors in accordance with agreed-upon configuration planning with the City.	Proposers are encouraged, but not required, to provide additional information in the Comments column to further demonstrate the system’s ability to meet the requirement.
F	Future: Feature/Function will be available in a future software release available to the City by July 1, 2024, at which point it will be implemented in accordance with agreed-upon configuration planning with the City.	If a response indicator of “F” is provided for a requirement that will be met in a future software release, the Proposer shall indicate the planned release version, as well as the time the release will be generally available.
C	Customization: Feature/Function is not included in the current software release and is not planned to be a part of a future software release. However, this feature could be provided with custom modifications. All related customization costs should be indicated in Attachment C – Cost Worksheet.	If a response indicator of “C” is provided for a requirement that will be met through a custom modification, the Proposer shall indicate the cost of such a modification.
T	Third Party: Feature/Function is not included in the current software release and is not planned to be a part of a future software release. However, this feature could be provided with integration with a third-party system. This system should be specified.	If a response indicator of “T” is provided for a requirement that will be met by integration with a third-party system, the Proposer shall identify this third-party system and include a cost proposal to secure this system. If the third-party system is a part of the proposal, the third-party shall respond to the appropriate requirements using the “S”/”C”/”T”/”N” response indicators with a clear notation that the responses are provided by the third-party.
N	No: Feature/Function cannot be provided.	N/A
General and Technical
Req	Description of Capability	Critical	Vendor Response	Comments
Technical Environment
GT.1	The system shall flow all changes made in the system throughout all proposed system modules without the need for duplicate data entry.	Critical
GT.2	The system shall support import and export data with web services formats.	Critical
GT.3	The system shall integrate with third-party signature validation systems (e.g., DocuSign).	Critical
GT.4	The system shall support APIs (Application Programming Interface) for third-party system integration, including both data entry and extraction, as well as execute workflows or initiate processes.	Critical
The system shall import and export data from (or to) standard file formats including but not limited to:
GT.5	.html;	Critical
GT.6	PDFs that are text based and searchable;	Critical
GT.7	.txt;	Critical
GT.8	csv;	Critical
GT.9	.xlsx (MS Excel version 2016 or later, including MS 365);	Critical
GT.10	.docx (MS Word version 2016 or later, including MS 365);	Critical
GT.11	.ics (MS Outlook version 2016 or later, including MS 365, for calendaring);	Critical
GT.12	.xml; and	Critical
GT.13	Other City-defined desktop productivity applications.	Critical
GT.14	The system shall provide a toolkit to create and manage API's, in an easy user-friendly interface.	Critical
GT.15	The system shall support API's (Application Programming Interface) for third-party system integration.	Critical
GT.16	The system has its own API keys and connectors for third-party and in-house system integration.	Critical
GT.17	The system shall support secure API traffic.	Critical
GT.18	The system shall encrypt all data states (e.g., restful, in motion) at all times at a minimum level of AES 128.	Critical
GT.19	The system shall encrypt all data states (e.g., restful, in motion) at all times at a minimum level of AES 256.	Desired
GT.20	The system shall support event-based data feeds for exchanging file import/exports with third-party systems.	Critical
GT.21	The system shall provide a centralized data dictionary that fully describes table structure, interdependencies, and appropriate levels of metadata.	Critical
GT.22	The system shall store and apply digital copies of signatures to documents (e.g., checks, notification letters) with appropriate security permissions.	Critical
GT.23	The system shall support application of certificate verified internal electronic signatures providing assurance of authenticity, integrity, and non-repudiation.	Critical
GT.24	The system shall operate on mobile devices (e.g., tablets, smart phones) and size-render appropriately.	Critical
GT.25	The system shall adhere to all applicable ADA related regulations for application performance and user interface.	Critical
GT.26	The system shall be device agnostic when run on mobile devices (e.g., the system can be run on Android, iOS, Windows, etc.).	Critical
GT.27	The system shall provide a production, test, development, and training environment including the ability to track software changes applied to each environment and roll back as necessary.	Critical
Document Management
GT.28	The system shall provide "Document Management System" functionality to track electronic files associated with specific system records.	Critical
GT.29	The system shall support data storage with discrete version control in accordance with defined operational standards.	Critical
GT.30	The system shall provide the ability to link imported documents to specific records.	Critical
GT.31	The system shall use "drag and drop", electronic file upload and scan document functionality to associate electronic files to transactions within the system.	Critical
GT.32	The system shall restrict modification of attached documents based on individual or department permissions based on user-defined criteria.	Critical
GT.33	The system shall allow a user to scan documents directly into the system.	Critical
GT.34	The system shall permit export of a file directly for document storage, for example in a third-party system or network drive.	Critical
GT.35	The system shall email a hyperlink of an electronic file to another internal party.	Critical
GT.36	The system shall allow email of an electronic file to an internal or external party (e.g., send a copy of a purchase order to a vendor).	Critical
GT.37	The system shall identify records with documentation/attachments.	Critical
GT.38	The system shall associate electronic files with a system record with the following types: e.g., MS Excel, MS Word, shape, PDF, .dwg, .tiff, .jpg.	Critical
GT.39	The system shall allow the City to restrict or define allowable file types.	Critical
GT.40	The system shall allow the City to set file size limitations.	Critical
GT.41	The system shall allow the City to electronically stamp documents with appropriate user-defined security permissions.	Critical
GT.42	The system shall limit the number of records generated in a query, with a notification to the user of an incomplete data set.	Critical
GT.43	The system shall support the purging of linked electronic files, according to City defined schedules, allowing for differing schedules based on the document, module, and/or litigation hold.	Critical
GT.44	The system shall support the archiving of linked electronic files, according to City defined schedules, allowing for differing schedules based on the document, module, and/or litigation hold.	Critical
GT.45	The system shall support automation of both purging and archiving of linked electronic files, allowing for movement from a production to secondary system location (without leaving the primary system), based on document, module, retention schedules, and/or litigation hold.	critical
GT.46	The system shall have the capability to assign document or attachment classification based on user-defined criteria and workflows.	Critical
GT.47	The system shall have the capability to maintain documents or attachments securely based on classification that has been assigned according to user-defined criteria and workflows.	Critical
GT.48	The system shall electronically capture and store files, with Optical Character Recognition (OCR) capabilities that has the ability to assign classification, secure documents based on that classification, and restrict user access according to assigned security permissions.	Critical
Security
GT.49	The system shall utilize the organization's authentication protocol ( AD/ADFS, Azure, Cisco Duo, Palo Alto, etc.). (https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/auth-sync-overview)	Critical
GT.50	The system shall support multi-factor authentication (MFA).	Critical
GT.51	The system has the ability to support detailed identity management.	Desired
GT.52	The system shall utilize the existing Active Directory user authentication regardless of deployment method.	Critical
GT.53	The system shall support Single Sign-On (SSO).	Critical
GT.54	The system shall inherit groups from Active Directory for application authentication.	Critical
Reporting and Dashboards
GT.55	The system shall provide an Executive Information System (EIS) (i.e., a performance dashboard).	Critical
GT.56	The system shall customize the information presented on the EIS by user.	Critical
GT.57	The system shall customize the information presented on the EIS by group of users.	Critical
GT.58	The system shall display information on the EIS in real-time.	Critical
GT.59	The system shall provide a library of standard reports (i.e., "canned" reports).	Critical
GT.60	The system shall allow a user to modify existing reports, with appropriate security permissions.	Critical
GT.61	The system shall provide an integrated report writer.	Critical
GT.62	The system shall provide an integrated report writer that has a consistent look and feel across all proposed system modules.	Critical
GT.63	The system shall provide an integrated report writer that allows the creation of reports comprised of any discrete data field throughout the system with proper security permissions.	Critical
GT.64	The system shall save a report as a new template after a user copies and modifies an existing report, with appropriate security permissions.	Critical
GT.65	The system shall configure and save ad hoc reports by individual user, with the ability to provide access to other users with appropriate security permissions.	Critical
GT.66	The system has the ability save favorite reports in a menu or pick-list by individual user.	Critical
GT.67	The system shall allow generated reports to be viewed on screen prior to printing.	Critical
GT.68	The system shall allow reports to be generated that are searchable.	Critical
GT.69	The system shall configure automatic distribution paths for generated reports (i.e., automatically send a report to a particular user).	Critical
GT.70	The system shall configure automatic distribution paths for batch reports (i.e., automatically send a report to a particular user or groups of users).	Critical
GT.71	The system shall allow reports to be generated that have "drill-down" capabilities.	Critical
GT.72	The system shall print graphs and charts for presentation style reports.
Critical
Vendor Support
GT.73	The vendor will schedule planned outage times to be outside standard City business hours.	Critical
GT.74	The vendor will coordinate any scheduled maintenance or outages with the City's Control Boards and not execute any changes until permission is gained from the City.	Critical
GT.75	The vendor will provide support during and outside standard City business hours.	Critical
GT.76	The vendor will notify the City of any changes to the City's database or applications as a result of support actions.	Critical
GT.77	The vendor will notify the City of any unanticipated changes to the City's database or applications as a result of support actions.	Critical
GT.78	The system shall provide an online tutorial to assist users learning the software.	Critical

&"Arial,Bold"&14City of Cleveland &"Arial,Regular"&11List of Functional and Technical Requirements

&"Arial,Regular"&10Attachment B &"Arial,Regular"&10Page &P of &N &"Arial,Regular"&10Last Updated: November 28, 2023

2. Data Conversion

	Potential Data Conversion(s)
	Req #	Data Conversion Object	Source	Quantity of Data Available	Quantity of Data Needed in Future System	City Criticality	Vendor Response	Cost to Convert	Vendor Standard Conversion Scope
(Please outline standard scope of conversions for the objects identified)	Vendor Comments
	DC.1	Employee Demographic Information	ADP	7,000 - 7,500 Active employees	All active employees	Critical				Proposed In-Scope
	DC.2	Employee Demographic Information	ADP	14,000 inactive employees	All inactive employees is preferred.	Desired				Proposed - Scope Varies from Requested Scope
	DC.3	Employee Demographic Information	ADP	14,000 inactive employees	Terminated in the current year.	Critical				Other (State Reasons in Vendor Comments)
	DC.4	Time and Attendance	ADP	2003 - Present	6 years preferred (willing to go to 2 years if needed)	Critical				Not Proposed
	DC.5	Accrual and Leave Data and time off balances	ADP	2003 - Present	6 years	Critical
	DC.6	Employee Pay	ADP	2003 - Present	6 years	Critical
	DC.7	Employee Deduction	ADP	2003 - Present	6 years	Critical
	DC.8	Benefit Enrollment and ACA History	ADP	2003 - Present	6 years	Critical
	DC.9	Applicant Data	NEOGOV	2016 - Present	5 years (active) and 2 years (archive)	Critical
	DC.10	LMS Content	BizLibrary	2022 - Present	All content	Critical
	DC.11	Time and Attendance	Kronos	2006- Present	6 years	Critical
	DC.12	EMS Employee Relations	IAPRO BlueTeam	2018 - Present	All content	Critical
	DC.13	Public Safety Scheduling	Telestaff	2012- Present	10 years	Critical
	DC.14	Staff Relations (Employee Discipline)	ADP	2003 - Present	5 years (active) and 5 years (active)	Critical

&"Arial,Bold"&14City of Cleveland &"Arial,Regular"&11List of Functional and Technical Requirements

&"Arial,Regular"&10Attachment B &"Arial,Regular"&10Page &P of &N &"Arial,Regular"&10Last Updated: November 28, 2023

3.Interfaces

	Potential Information Exchanges					Yes	Standard - File Import
	A list of potential information exchanges for the future software environment has been developed and presented in this tab. In several instances, integration/interfacing/data transfer items presented in this list may not be required if the proposed software system can provide needed functionality. Conversely intended replacements of existing third-party systems may be adjusted if functionality in the future selected system is not adequate. As a result, the following list of potential interfaces for vendors to respond to so that the future applications environment may be considered. The types of information exchanges are:					No	Standard - File Export
	Interface
Also known as a bridge, an interface is where two or more separate software products communicate under limited capacity. An interface will often use a standard file format such as XML to move information from one system to another. Some interfaces are separate programs that can be configured and deployed with a range of systems (e.g. Microsoft BizTalk). Examples of common Interface mechanisms include Application Program Interface (API) and web services.			Integration
A system where the different products or modules are tightly connected to function as one solution. In an integration, the systems share the same code and database.		Data transfer/exchange
A specialized interface where data is extracted from one application, usually as a data export using a specified file format, and placed in a specified location, such as a folder on a shared network drive. Another application retrieves the file, reads and imports the data. The file transfer process between the applications can be manual or automated using a scheduler to direct the applications when to export or import the data. The transfer process may be scheduled to occur as needed.				Optional	Standard - File Import/Export
	The ways in which the proposed system, and the systems identified below, may interact in terms of passing information back and forth, are as follows:

SEND: The Selected system will only need to SEND data to the third party application.

RECEIVE: The Selected system will only need to RECEIVE date from the third party application.

BOTH: The Selected system will need to both SEND and RECEIVE information to/from the third party application.

N/A - Functionality Provided by Proposed Solution (Communication between systems not needed)

Standard - Interface/API

Req #

System Type

Product and Version

Desired Type of Data Transfer

Desired Frequency of Data Transfer

Data Involved in Potential Transfer

Vendor Response

Vendor Comments

Included in scope of proposal?

Cost to Develop for host and target systems

Published API?

Standard - Other (Explain in comments)

INT.1

ERP

CGI

Interface - Send and Receive Data

Near-Immediate (real-time)

Send: The new HCM system will need to send employee, position, benefit enrollment, and time entry, and payroll data to the legacy ERP system.

Receive: The new HCM system will need to receive employee, position data and any changes to the GL from the legacy ERP system.

Custom Interface (Explain in comments)

INT.2

Learning management system (Public Safety)

Target Solutions

Interface - Send and Receive Data

Near-Immediate (real-time)

Send: The HCM system will need to send employee data (changes in employee status) to TargetSolutions.

Receive: The HCM system will need to receive employee demographic and certification information from Target Solutions (if this functionality is not proposed) for the purposes of updating the personnel file.

Custom Integration (Explain in comments)

INT.3

Learning management system (DPU)

HSI Workplace

Compliance Solutions

(Safety Training)	Interface - Send and Receive Data	Near-Immediate (real-time)	Send: The HCM system will need to send employee data (changes in employee status) to HSI Workplace Solutions
Receive: The HCM system will need to receive employee demographic and certification information from HSI Workplace Solutions (if this functionality is not proposed) for the purposes of updating the personnel file.							Existing Interface Developed (Explain in comments)
	INT.4	Learning management system (Airport)	Noverant	Interface - Send and Receive Data	Near-Immediate (real-time)	Send: The HCM system will need to send employee data (changes in employee status) to the Airport LMS
Receive: The HCM system will need to receive employee demographic and certification information from Target Solutions (if this functionality is not proposed) for the purposes of updating the personnel file.							Existing Interface Developed (Explain in comments)
	INT.5	Productivity tools	Microsoft Office 365	Interface - Send and Receive Data	Near-Immediate (real-time)	Send: The HCM system will need to provide file import and export capability to/from Microsoft applications.

Receive: Microsoft applications (MS Word, MS Excel, MS SharePoint, MS Teams, PowerApps, and Access) files will need to be imported in the HCM system.

							Not Applicable (Explain in comments)
	INT.6	Public safety time tracking and scheduling	Telestaff	Interface - Send and Receive Data	Near-Immediate (real-time)	Send: The HCM system will need to send employee data to the attendance tracking system.
Receive: The HCM system will need to receive time data from the attendance tracking system.							Functionality Proposed to Replace the Specified System
	INT.7	Benefit Providers	Benefit Providers	Interface - Send and Receive Data	Near-Immediate (real-time)	Send: The HCM system will need to send new user information to update AD for user authentication.

Receive: The HCM systems will need to receive employee benefit elections and/or deductions from benefit providers.

INT.8 Active Directory Authentication Microsoft Azure Cloud Interface - Send and Receive Data Near-Immediate (real-time) Send: The HCM will need to send new user information to update AD for user authentication.

Receive: The HCM system will need to receive new user information to update AD for user authentication.

INT.9 Employment eligibility verification eVerify Interface - Send and Receive Data Near-Immediate (real-time) Send: The HCM system will need to have the ability to send HR employee data for I-9 verification.

Receive: The HCM system will need to receive verification status from eVerify.

INT.10 Substance Testing Concentra Interface - Send and Receive Data Near-Immediate (real-time) Send: The HCM system will need to send employee data to Concentra for the purpose of creating randomized lists for substance testing.

Receive: The HCM system will need to receive test results from Concentra.

INT.11 CI Technology IAPRO BLUETEAM Interface - Send and Receive Data Near-Immediate (real-time) Send: The HCM will need to send employee data.

Receive: The HCM will need to receive performance evaluation results from CI Technology for the purpose of updating the employee file.

INT.12 Time Keeping Kronos Interface - Send and Receive Data Near-Immediate (real-time) *Should functionality not be proposed* Send: The HCM system will need to send employee data to the time tracking system.

Receive: The HCM system will need to receive time data from the time tracking system for the purpose of payroll.

INT.13	Access Control	Linel S2	Interface - Send data from selected system	Near-Immediate (real-time)	Send: The HCM system will need to send employee data (hiring and termination to terminate access) in Linel S2.
INT.14	Access Control	Honeywell	Interface - Send data from selected system	Near-Immediate (real-time)	Send: The HCM system will need to send employee data (hiring and termination to terminate access) to Linel S2.
INT.15	Third-Party FMLA Vendor	Sedgwick	Interface - Send and Receive Data	Near-Immediate (real-time)	Send: The HCM will need to send employee data to Sedgwick.
INT.16	Payroll direct deposit advises	Huntington	Interface - Send data from selected system	Near-Immediate (real-time)	Receive: The HCM will need to receive a bank file from Huntington.

&"Arial,Bold"&14City of Cleveland &"Arial,Regular"&11List of Functional and Technical Requirements

&"Arial,Regular"&10Attachment B &"Arial,Regular"&10Page &P of &N &"Arial,Regular"&10Last Updated: November 28, 2023

4. Adv. Scheduling

Indicator	Definition	Instruction
S	Standard: Feature/Function is included in the current software release and will be implemented by the planned phase go-live date as part of the proposal from Vendors in accordance with agreed-upon configuration planning with the City.	Proposers are encouraged, but not required, to provide additional information in the Comments column to further demonstrate the system’s ability to meet the requirement.
F	Future: Feature/Function will be available in a future software release available to the City by July 1, 2024, at which point it will be implemented in accordance with agreed-upon configuration planning with the City.	If a response indicator of “F” is provided for a requirement that will be met in a future software release, the Proposer shall indicate the planned release version, as well as the time the release will be generally available.
C	Customization: Feature/Function is not included in the current software release and is not planned to be a part of a future software release. However, this feature could be provided with custom modifications. All related customization costs should be indicated in Attachment C – Cost Worksheet.	If a response indicator of “C” is provided for a requirement that will be met through a custom modification, the Proposer shall indicate the cost of such a modification.
T	Third Party: Feature/Function is not included in the current software release and is not planned to be a part of a future software release. However, this feature could be provided with integration with a third-party system. This system should be specified.	If a response indicator of “T” is provided for a requirement that will be met by integration with a third-party system, the Proposer shall identify this third-party system and include a cost proposal to secure this system. If the third-party system is a part of the proposal, the third-party shall respond to the appropriate requirements using the “S”/”C”/”T”/”N” response indicators with a clear notation that the responses are provided by the third-party.
N	No: Feature/Function cannot be provided.	N/A
Advanced Scheduling
Req #	Description of Requirement	Criticality	Vendor Response	Comments
General Requirements
SCH.1	The system shall provide a scheduling module that is integrated with the time/attendance module.	Critical
The system shall accommodate the following types of schedules:
SCH.2	Group schedules;	Critical
SCH.3	Individual schedules;	Critical
SCH.4	Rotation schedules;	Critical
SCH.5	Shift Schedules;	Critical
SCH.6	Post;	Critical
SCH.7	On-call/standby;	Critical
SCH.8	Demand-based schedules; and	Critical
SCH.9	Other, user-defined.	Critical
SCH.10	The system shall support a minimum of 200 schedules, including user-defined schedules.	Critical
The system shall maintain the following tables for schedule creation:
SCH.11	Shift;	Critical
SCH.12	Division;	Critical
SCH.13	Rotation (number of days on and off);	Critical
SCH.14	Work positions;	Critical
SCH.15	Work assignments;	Critical
SCH.16	Leave types (sick, vacation, military, etc.); and	Critical
SCH.17	Mandatory or non-mandatory fill position indicator.	Critical
SCH.18	The system shall accommodate unlimited schedule changes and adjustments on demand.	Critical
The system shall maintain various defined shifts with the following characteristics and information:
SCH.19	Varying hours per shift;	Critical
SCH.20	Start times;	Critical
SCH.21	End times;	Critical
SCH.22	Duration;	Critical
SCH.23	Multiple shift patterns;	Critical
SCH.24	Multiple employee roles;	Critical
SCH.25	Required certifications of resources for the shift;	Critical
SCH.26	Multiple locations;	Critical
SCH.27	Multiple sub-locations; and	Critical
SCH.28	Multiple skill requirements.	Critical
SCH.29	The system shall maintain at least 50 different shift configurations in the table of defined shifts.	Critical
SCH.30	The system shall prohibit resources from being scheduled for a particular shift that do not meet prescribed requirements.	Critical
SCH.31	The system shall override restrictions on employees being scheduled for a particular shift.	Critical
SCH.32	The system shall assign the number of personnel required each day for defined positions.	Critical
SCH.33	The system shall identify variances (both positive and negative) between required number of personnel and actual scheduled for a given position on a given day.	Critical
SCH.34	The system shall assign the number of personnel required at each location for defined positions and days (e.g., minimum clerical staff at a particular office on Mondays).	Critical
SCH.35	The system shall identify variances (both positive and negative) between required number of personnel and actual scheduled for a given location on a given day.	Critical
SCH.36	The system shall create calendars/rosters of projected absences.	Critical
The system shall utilize department roles for automated staffing including the following characteristics and information:
SCH.37	Staffing minimums;	Critical
SCH.38	Roster vacancies due to leave time; and	Critical
SCH.39	Insufficient "qualified" candidates (e.g., certifications, etc.).	Critical
SCH.40	The system shall automatically contact employees via telephone, email, text messaging and web to offer an assignment (e.g., overtime availability, open shifts) and update the real-time roster.	Critical
SCH.41	The system shall support the shift bid process for certain eligible groups of employees.	Critical
SCH.42	The system shall support the time off bid process for certain eligible groups of employees.	Critical
SCH.43	The system shall support the overtime bid process for certain eligible groups of employees.	Critical
SCH.44	The system shall allow the configuration of the order in which employees are contacted based on any data field in the employee master file (e.g., seniority, last shift worked, etc.).	Critical
SCH.45	The system shall maintain a log of all employees who have been contacted.	Critical
SCH.46	The system shall produce a list for each absence by rules and create the call log.	Critical
The system shall support multiple notification methods including but not limited to:
SCH.47	Telephone;	Critical
SCH.48	Text Messaging/SMS;	Critical
SCH.49	Cell phone; and	Critical
SCH.50	Email.	Critical
SCH.51	The system shall accommodate work time trades between employees.	Critical
SCH.52	The system shall allow time to be tracked using either AM/PM or military time.	Critical
SCH.53	The system shall define split shift rotations.	Critical
SCH.54	The system shall identify employee as unavailable for overtime for a given time period and specify reason.	Critical
SCH.55	The system shall schedule shifts that cross multiple days (e.g., start at 6:00 p.m. on one day and complete at 2:00 a.m. on day two).	Critical
SCH.56	The system shall define workload restrictions for each position. These could include number of hours between shifts, maximum hours worked per regular shift, maximum overtime hours per time period.	Critical
The system shall define workload restrictions for each position including (but not limited to) the following:
SCH.57	Number of hours between shifts;	Critical
SCH.58	Maximum hours worked per regular shift;	Critical
SCH.59	Maximum hours worked per regular week; and	Critical
SCH.60	Maximum overtime hours per time period.	Critical
SCH.61	The system shall override workload restrictions.	Critical
SCH.62	The system shall override workload restrictions with appropriate permissions.
Critical
SCH.63	The system shall implement alternate schedules (e.g., ad-hoc schedules for circumstances of single occurrence).	Critical
SCH.64	The system shall temporarily assign employees.	Critical
SCH.65	The system shall view multiple schedules at once.	Critical
SCH.66	The system shall publish and print an official/final schedule.	Critical
SCH.67	The system shall preserve the schedule in the event the system is unavailable due to planned or unplanned downtime.	Critical
SCH.68	The system shall identify an assignment that conflicts with a rule.	Critical
SCH.69	The system shall define a mandatory-overtime backfill list based on prescribed business rules.	Critical
SCH.70	The system shall alert a shift scheduler when assignment conflicts with a rule.	Critical
SCH.71	The system shall schedule meals and breaks, as well as start and end times.	Critical
SCH.72	The system shall support various schedules.	Critical
SCH.73	The system shall support user-defined flex schedules (e.g., 50/30, etc.).	Critical
SCH.74	The system shall calculate overtime based on FLSA regulations.	Critical
SCH.75	The system shall view and maintain all previous schedules.	Critical
SCH.76	The system shall route an alert/notification when defined hour-limit is reached.	Critical
SCH.77	The system shall populate Entities holidays and other closures in the schedule, system-wide.	Critical
SCH.78	The system shall support varying types of scheduled weeks, including 48/60/72 hour weeks for public safety.	Critical
SCH.79	The system shall support varying types of scheduled weeks, including 36/45.23/48 hour weeks.
Critical
SCH.80	The system shall accommodate department schedules with two shifts, three shifts, 24 hours per shift, and user defined shifts.
Critical
SCH.81	The system shall accommodate out of class work paid based on hours worked in the out of class position.	Critical
Reporting & Querying
SCH.82	The system shall use a single data source for report generation.	Critical
SCH.83	The system shall generate "canned" reports that users may run with limited options of input values.	Critical
SCH.84	The system shall generate user-defined reports on any time entry field and/or combination of fields.	Critical
SCH.85	The system shall provide an ad-hoc reporting tool without the use of a third-party report writing tool.	Critical
SCH.86	The system shall provide role-based security on running and viewing reports.	Critical
SCH.87	The system shall import data from reports into standard applications for spreadsheet comparison, graphing, etc.	Critical
The system shall generate reports on time worked by the following:
SCH.88	Location;	Critical
SCH.89	Department;	Critical
SCH.90	Division;	Critical
SCH.91	Team;	Critical
SCH.92	Task/Work Order;	Critical
SCH.93	Project;	Critical
SCH.94	Job;	Critical
SCH.95	Grant;	Critical
SCH.96	Activity;	Critical
SCH.97	Leave type;	Critical
SCH.98	Hours paid by individual;	Critical
SCH.99	Hours entered (by type);	Critical
SCH.100	Position;	Critical
SCH.101	Event;	Critical
SCH.102	Work group;	Critical
SCH.103	Shift;	Critical
SCH.104	Time errors;	Critical
SCH.105	Employee status; and	Critical
SCH.106	Other user-defined.	Critical
SCH.107	The system shall generate a year-to-date report (calendar or fiscal year) of time worked by employee.	Critical
SCH.108	The system shall provide a report filtered by location that identifies the total number of hours worked per employee in a pay period or by year.	Critical
SCH.109	The system shall generate a report of part-time employee hours worked on a year-to-date basis to monitor for hours worked exceeding user defined parameters.	Critical
SCH.110	The system shall provide audit trail reporting of all data entries, changes, and deletions by user, date, time, and work station	Critical

&"Arial,Bold"&14City of Cleveland &"Arial,Regular"&11List of Functional and Technical Requirements

&"Arial,Regular"&10Attachment B &"Arial,Regular"&10Page &P of &N &"Arial,Regular"&10Last Updated: November 28, 2023

5. Applicant Tracking

Indicator	Definition	Instruction
S	Standard: Feature/Function is included in the current software release and will be implemented by the planned phase go-live date as part of the proposal from Vendors in accordance with agreed-upon configuration planning with the City.	Proposers are encouraged, but not required, to provide additional information in the Comments column to further demonstrate the system’s ability to meet the requirement.
F	Future: Feature/Function will be available in a future software release available to the City by July 1, 2024, at which point it will be implemented in accordance with agreed-upon configuration planning with the City.	If a response indicator of “F” is provided for a requirement that will be met in a future software release, the Proposer shall indicate the planned release version, as well as the time the release will be generally available.
C	Customization: Feature/Function is not included in the current software release and is not planned to be a part of a future software release. However, this feature could be provided with custom modifications. All related customization costs should be indicated in Attachment C – Cost Worksheet.	If a response indicator of “C” is provided for a requirement that will be met through a custom modification, the Proposer shall indicate the cost of such a modification.
T	Third Party: Feature/Function is not included in the current software release and is not planned to be a part of a future software release. However, this feature could be provided with integration with a third-party system. This system should be specified.	If a response indicator of “T” is provided for a requirement that will be met by integration with a third-party system, the Proposer shall identify this third-party system and include a cost proposal to secure this system. If the third-party system is a part of the proposal, the third-party shall respond to the appropriate requirements using the “S”/”C”/”T”/”N” response indicators with a clear notation that the responses are provided by the third-party.
N	No: Feature/Function cannot be provided.	N/A
Recruitment/Applicant Tracking
Req #	Description of Requirement	Critical	Vendor Response	Comments
Job Requisitions
REC.1	The system shall provide a Recruitment module that is integrated with all other proposed system modules such as the Employee File, Payroll, Time Entry and Benefits.	Critical
REC.2	The system shall provide audit trail reporting of all data entries, changes and deletions by user, date, time and workstation.	Critical
REC.3	The system has the ability to reset job requisitions upon calendar year end.	Critical
REC.4	The system shall provide mobile optimization (e.g., allow for resizing and formatting of the applicant screen if viewed on a mobile device such as cell phone or tablet).	Desired
The system shall generate electronic requisitions to fill vacancies, containing:
REC.5	Department number;	Critical
REC.6	Division;	Critical
REC.7	Remote Work;	Desired
REC.8	Location;	Critical
REC.9	Shift;	Critical
REC.10	Position number;	Critical
REC.11	Job/Position title;	Critical
REC.12	Class code;	Critical
REC.13	Status (full-time/part-time, permanent/temporary);	Critical
REC.14	Reason for vacancy (e.g., promotion, transfer, termination, etc.);	Critical
REC.15	Date vacancy created;	Critical
REC.16	Date requisition created;	Critical
REC.17	Date needed;	Critical
REC.18	Closing date (date field);	Critical
REC.19	Open until filled (Yes/No);	Critical
REC.20	Pay grade;	Critical
REC.21	Salary range (with no min or max limits i.e., not limited to the positions salary range);	Critical
REC.22	Multiple budget account codes;	Critical
REC.23	Recruitment type (general public, City only, department only);	Critical
REC.24	Exempt/non-exempt status;	Critical
REC.25	User-defined special requirements for the position (e.g., CDL);	Critical
REC.26	Multiple hiring officers/Division Director;	Critical
REC.27	Contact name;	Critical
REC.28	Contact phone;	Critical
REC.29	Requisition status (close, re-open, or update requisition); and	Critical
REC.30	Other user-defined fields.	Critical
REC.31	The system shall, upon creation of a job requisition, create a system-generated requisition number and creation date based on the system date (real date).	Critical
REC.32	The system shall tie a requisition to a specific job code.	Critical
REC.33	The system shall establish classes (or categories/types) of requisitions.	Critical
REC.34	The system shall pre-populate requisition fields based on position control number (e.g., salary ranges, job description) with the ability to override.	Critical
REC.35	The system shall allow users to copy information from a previously submitted requisition to a new one.	Critical
REC.36	The system shall restrict entry of personnel requisitions to only those eligible and fully funded positions with a position control number (e.g., vacancies).	Critical
REC.37	The system shall restrict entry of personnel requisitions to only one in-progress (e.g., submitted, pending, held) requisition per available position control number at a time. This intends to restrict two or more requisitions being entered for the same available position.	Critical
REC.38	The system shall support both internal and external posting of job openings that are open to a single or multiple departments (e.g., advertise only to water vs. advertise City-wide).	Critical
REC.39	The system shall restrict user access to requisitions according to user-defined authorization rules.	Critical
REC.40	The system shall allow authorized users to search within any field within the requisition for the purposes of querying and ad-hoc report creation.	Critical
The system shall allow authorized users to view and sort all job requisitions on various fields, including (but not limited to):
REC.41	Requisition number/ID;	Critical
REC.42	Requisition creation date;	Critical
REC.43	Requisition status (open/closed);	Critical
REC.44	Filled requisitions; and	Critical
REC.45	Other user-defined.	Critical
REC.46	The system shall tie requisitions to job codes (or other City-defined codes), allowing for sorting/querying based on classification.	Critical
REC.47	The system shall ensure appropriate approvals have been received on position requests.	Critical
REC.48	The system shall set a user-defined job posting time period.	Critical
REC.49	The system shall permit authorized users to close or delete a requisition manually.	Critical
REC.50	The system shall automatically close the requisition when the hiring process has been completed (i.e., if a one-to-one ratio between the requisition and the number of vacancies being filled).	Critical
REC.51	The system shall automatically track "Date of last update," including name of user making the last saved update.	Critical
REC.52	The system shall notify requestor when a user-defined position has been approved and initiate other related events (e.g., recruitment process).	Critical
REC.53	The system shall establish varying workflow rules based on whether a requisition entered is for filling a vacancy versus a reclassification of a position (e.g., position control Request).	Critical
REC.54	The system shall auto-populate job postings with job description data.	Critical
REC.55	The system shall override and modify the job posting (e.g., narrative blurb about that position) and maintain version history (e.g., information prior to any changes made) with appropriate security.	Critical
REC.56	The system shall forward job postings to managers for review/updates/edits (via workflow).	Critical
REC.57	The system shall indicate job posting type (internal/external recruitment) and post as designated.	Critical
REC.58	The system shall assign job postings to a specific recruiter or staff member(s) within HR.	Critical
The system shall display the following information on the job posting:
REC.59	Department;	Critical
REC.60	Location;	Critical
REC.61	Shift;	Critical
REC.62	Job/Position title;	Critical
REC.63	Job category (safety sensitive, CDL, etc.);	Critical
REC.64	Status (full-time/part-time, permanent/temporary);	Critical
REC.65	Open date;	Critical
REC.66	Closing date (date field);	Critical
REC.67	Open until filled (Yes/No);	Critical
The system shall maintain, at a minimum, the following applicant data:
REC.68	Applicant Name;	Critical
REC.69	Previous Name(s);	Critical
REC.70	Date of application;	Critical
REC.71	Time of application;	Critical
REC.72	Source of application information;	Critical
REC.73	Address;	Critical
REC.74	Phone number/s;	Critical
REC.75	Email address/es;	Critical
REC.76	Positions applied/referred for;	Critical
REC.77	Ability to be legally employed in the USA (Y/N);	Critical
REC.78	Reference detail;	Critical
REC.79	Verification that references can be called (specific to each reference);	Critical
REC.80	Indicator/Flag for current employer (e.g., do not contact current employer);	Critical
REC.81	Attached resume (consistent with general file formats);	Critical
REC.82	Attached other supporting documentation (consistent with general file formats);	Critical
REC.83	Previous employment information (e.g., previous salary, hours worked, title, dates of employment);	Critical
REC.84	Scheduling availability for days of work	Critical
REC.85	Previously employed by the City (Y/N);	Critical
REC.86	Education;	Critical
REC.87	Veteran Status or Military Service;	Critical
REC.88	Certificates/licensure;	Critical
REC.89	Driver's License Number;	Critical
REC.90	Driver's License State Issued;	Critical
REC.91	Driver's License Class;	Critical
REC.92	Supplemental Questions (position specific);	Critical
REC.93	Relatives employed by the City;	Critical
REC.94	Other skills;	Critical
REC.95	Other user-defined.	Critical
REC.96	The system has the ability to restrict applicants from reapplying within a specific time frame.	Critical
REC.97	The system shall save applicant data upon initial entry for user's profile with blocks prefilled for multiple application submissions with the ability to override.	Critical
The system shall track EEO and demographic data for use in statistical analysis and reporting, including but not limited to:
REC.98	Requisition Number;	Critical
REC.99	Interviewed Flag;	Critical
REC.100	Applicant name;	Critical
REC.101	Applicant ID;	Critical
REC.102	Applicant Record Number;	Critical
REC.103	Applicant address;	Critical
REC.104	Home phone;	Critical
REC.105	The system shall redact identifying information (Name, DOB, etc.) from an application prior to submission to a hiring manager.	Critical
REC.106	The system shall track ADA requests with an applicant.	Critical
REC.107	The system shall notify defined users when an ADA accommodation request has been submitted.	Critical
REC.108	The system shall track ADA accommodations with an applicant.	Critical
REC.109	The system shall apply user-defined scoring criteria to any field in the application, including supplemental questions.	Critical
REC.110	The system shall support EEO and ADA analysis.	Critical
REC.111	The system shall flag applicant records based on user-defined criteria (e.g., termed employee unable to reapply, applicant rejected due to criminal background results).	Critical
Online Employment Application
REC.112	The system shall provide an online employment application interface.	Critical
REC.113	The system shall support for online employment application from a mobile device.	Critical
REC.114	The system shall allow job posting web pages to be customized to match the City website in format, presentation, and other characteristics as defined by the City.	Critical
REC.115	The system shall restrict user-access through use of user-ID and password.	Critical
REC.116	The system shall administer password changes and revisions to support applicant needs.	Critical
REC.117	The system shall allow an applicant user to manage password changes and revisions to support applicant needs.	Critical
REC.118	The system shall store job postings and/or descriptions in an easily updated format.	Critical
REC.119	The system shall maintain job posting and/or description history, including prior versions and active dates.	Critical
REC.120	The system shall provide online completion of application on any Internet enabled computer through a web browser.	Critical
REC.121	The system shall provide a view for internal and external users for job postings available to both groups.	Critical
The system shall provide applicants with an interface with a variety of functions, including but not limited to:
REC.122	Instructions for system use;	Critical
REC.123	Create new employment application;	Critical
REC.124	Print job posting;	Critical
REC.125	Print application;	Critical
REC.126	Save application; and	Critical
REC.127	Suspend/withdraw application (before/after closing date).	Critical

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it. Updated May 11, 2025.