2-CO-Town of Parker RFI Workbook-CD.xlsx
XLSX spreadsheet 71 KB Posted
- Attached to
- RFI 26-011 Community Development Technology State and local contract opportunity
- Solicitation number
- 26-011
- Issued by
- Douglas County, Colorado
About this file
RFI 26-011 Community Development Technology Summary
This is a Request for Information (RFI) workbook issued by the Town of Parker, Colorado, in coordination with BerryDunn consulting, to evaluate and potentially replace the town's community development technology environment. The RFI seeks vendor responses regarding Enterprise Resource Planning (ERP) and Community Development software solutions that would support permitting, planning and zoning, inspections, code enforcement, electronic plan review, licensing, public portal services, and related community development functions. The workbook requires vendors to complete multiple worksheets addressing module availability, functionality capabilities, implementation approach, costs, informational questions, and integration with the town's future systems environment. The RFI document was finalized on May 7, 2026, though specific response due dates are not explicitly stated within the provided content.
The RFI workbook requires detailed vendor responses across six primary sections: (1) module and functionality availability using standardized response indicators; (2) implementation approach including professional services models, deployment options, project team roles, estimated work effort allocation, and anticipated project duration broken into implementation phases; (3) one-time and recurring cost estimates for software licensing, professional services, training, hardware, and third-party services; (4) informational questions regarding vendor experience, marketplace presence, competitive differentiators, and product roadmap; (5) data migration strategy and legacy system retention recommendations; and (6) integration approach for the town's existing systems including Bluebeam, CivicPlus, Esri ArcGIS, Laserfiche, TRAKiT, and other departmental applications. The town seeks to understand total cost of ownership, implementation timelines, resource requirements, and scalability while maintaining integration capabilities with its existing technology ecosystem.
View the file
Other files for this state and local contract opportunity
| File | Type | Posted |
|---|---|---|
| 1-RFI 26-011 Community Development Technology.pdf |
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
1. Availability of Modules
| Availability of Modules | |||
| Instructions for completing this worksheet: Please provide your responses to the tables below, including supporting narrative comments where applicable to help the Town better understand the responses given. | |||
| Response Indicators: | |||
| 1: The module is part of the integrated software package we provide. | |||
| 2: The module is not part of the software we provide; however, we regularly integrate with a third-party software product to provide this functionality. Identify this product in the comments. | |||
| 3: We do not provide this module. | |||
| No | Module | Vendor Response | |
| (1, 2, or 3) | Comments | ||
| 1 | Permitting & Inspection | ||
| 2 | GIS Integration | ||
| 3 | Planning & Zoning | ||
| 4 | Electronic Plan Review | ||
| 5 | Code Enforcement | ||
| 6 | Public Portal |
&"Arial,Bold"&12Request for Information:&"Arial,Regular" ERP and Community Development Software
&"Arial,Bold"&12Request for Information:&"Arial,Regular" ERP and Community Development Software
&"Arial,Bold"&12Request for Information:&"Arial,Regular" ERP and Community Development Software
&"Arial,Bold"&14Town of Parker &"Arial,Regular"Request for Information (RFI) Workbook
&"Arial,Regular"&10BerryDunn &"Arial,Regular"&10April XX, 2013
&"Arial,Regular"&10BerryDunn &"Arial,Regular"&10April XX, 2013
&"Arial,Regular"&10BerryDunn &"Arial,Regular"&10April XX, 2013
&"Arial,Regular"&10BerryDunn &"Arial,Regular"&10May 7, 2026
2. Avail. of Functionality
| Availability of Functionality | |||
| Instructions for completing this worksheet: Please provide your responses to the tables below, including supporting narrative comments where applicable to help the Town better understand the responses given. | |||
| Response Indicators: | |||
| F: "Fit" indicates the product or a feature meets the need of the requirement. | R: "Roadmap" indicates the capability is on the system's roadmap. Please describe the planned functionality and associated timeline for release in the Comments column. | ||
| G: "Gap" indicates the system cannot satisfy the requirement. | |||
| P: "Partial" indicates the system can meet some of the requirement but not all. Please describe limitations in the Comments column. | T: "Third-Party" indicates the system cannot satisfy the requirement. However, this feature could be provided with integration with a third-party system. This system should be specified in the Comments column. | ||
| No | Functionality | Vendor Response (F,G,P,R,T) | Comments |
| General and Technical | |||
| Technical Environment | |||
| GT.1 | The system shall have the ability to support a configurable, integrated application environment that allows changes made in one module to flow to related modules without duplicate data entry. | ||
| GT.2 | The system shall have the ability to support separate production, test, training, and development environments, including the ability to track configuration changes, software updates, and environment refreshes. | ||
| GT.3 | The system shall have the ability to support environment refreshes, including the ability to copy data and configuration from production to non-production environments using Town-defined timing and security controls. | ||
| GT.4 | The system shall have the ability to support browser-based access through current versions of major web browsers, including Microsoft Edge, Google Chrome, and Safari. | ||
| GT.5 | The system shall have the ability to support data retention, archive, purge, and retrieval rules based on Town-defined operational, legal, audit, and historical reporting requirements (e.g., capital project, asset lifecycle). | ||
| Data, Integration & Interoperability | |||
| GT.6 | The system shall have the ability to support data import and export using standard file formats, including CSV, XLSX, XML, PDF, DOCX, TXT, HTML, and other Town-defined formats. | ||
| GT.7 | The system shall have the ability to support APIs for third-party system integration, including data entry, data extraction, workflow initiation, status updates, and system-to-system communication. | ||
| GT.8 | The system shall have the ability to support secure scheduled data feeds, imports, exports, and automated file transfers with Town-defined third-party systems. | ||
| GT.9 | The system shall have the ability to support data export for public records, audit requests, analysis, reporting, and future system transitions without requiring vendor-developed custom extracts for standard data fields. | ||
| Security, Privacy & Audit | |||
| GT.10 | The system shall have the ability to support integration with the Town’s identity provider, including Entra ID/Azure. | ||
| GT.11 | The system shall have the ability to support multi-factor authentication for internal, external, mobile, and administrative users based on Town-defined security policies. | ||
| GT.12 | The system shall have the ability to support role-based security to restrict access to information and functions based on job role, department, user group, module, record type, data field, and other Town-defined criteria. | ||
| GT.13 | The system shall have the ability to support field-level security and data masking for sensitive information, including Social Security numbers, tax identification numbers, dates of birth, bank account information, health information, personal addresses, and other Town-defined confidential data. | ||
| GT.14 | The system shall have the ability to support multiple administrative roles, including technical administrators, functional administrators, department administrators, and read-only audit users. | ||
| GT.15 | The system shall encrypt data at rest and in transit using industry-standard encryption methods and secure key management practices. | ||
| GT.16 | The system shall capture audit log details including user ID, date, time, action performed, original value, updated value, affected record, and related module or process. | ||
| GT.17 | The system shall align with recognized cybersecurity and privacy frameworks applicable to the proposed solution, such as SOC 2 Type II, ISO 27001, NIST, CJIS, HIPAA, PCI, or other relevant standards, where applicable. | ||
| Document & Records Management | |||
| GT.18 | The system shall have the ability to support document management functionality that allows electronic files to be attached, linked, categorized, searched, viewed, retained, and retrieved from related system records. | ||
| GT.19 | The system shall have the ability to support drag-and-drop upload, scanned document capture, batch upload, and manual attachment of electronic files to transactions and records. | ||
| GT.20 | The system shall have the ability to support document version control, including the ability to retain prior versions, identify the current version, and view version history. | ||
| GT.21 | The system shall have the ability to support configurable allowable file types, file size limits, document categories, naming conventions, and required attachment rules. | ||
| GT.22 | The system shall have the ability to support electronic signatures, digital signatures, document stamping, approval signatures, and integration with third-party signature platforms where applicable. | ||
| GT.23 | The system shall have the ability to support document redaction, restricted document visibility, and confidential document handling based on Town-defined security rules. | ||
| GT.24 | The system shall have the ability to support document sharing through secure links, email, portal access, download, export, or integration with Town-defined document repositories. | ||
| GT.25 | The system shall have the ability to support records retention and litigation hold rules for electronic documents based on document type, module, record status, and Town-defined schedules. | ||
| GT.26 | The system shall have the ability to integrate with third-party document management systems (e.g., Laserfiche). | ||
| Workflow & Notifications | |||
| GT.27 | The system shall have the ability to support configurable workflows across proposed modules, including initiation, routing, approvals, task assignments, status tracking, escalations, notifications, and completion rules. | ||
| GT.28 | The system shall have the ability to support workflow routing based on user, role, department, division, record type, transaction type, amount threshold, location, or other Town-defined criteria. | ||
| GT.29 | The system shall allow authorized users to view where a record or transaction is in the workflow process, including current step, assigned user, pending action, due date, and workflow history. | ||
| GT.30 | The system shall have the ability to support workflow audit trails, including initiator, approver, reviewer, date and time, comments, decisions, status changes, and completed steps. | ||
| GT.31 | The system shall have the ability to support delegation, backup approvers, temporary user availability settings, and automated reassignment during absence, leave, vacancy, or non-response. | ||
| GT.32 | The system shall have the ability to support bulk review and approval of selected tasks or transactions where permitted by Town-defined business rules and security permissions. | ||
| GT.33 | The system shall have the ability to support event-driven notifications through email, in-system alerts, dashboards, mobile notifications, or other Town-defined communication methods. | ||
| GT.34 | The system shall allow authorized users to override, reroute, return, or advance a workflow step with required reason codes, audit trail, and security controls. | ||
| Reporting & Analytics | |||
| GT.35 | The system shall include a library of standard pre-built reports for operational, financial, administrative, compliance, audit, and management reporting needs. | ||
| GT.36 | The system shall have the ability to support an integrated, user-friendly report writer that allows authorized users to create and modify reports using available system data fields without advanced technical skills. | ||
| GT.37 | The system shall support ad hoc reporting capabilities, including the ability for users to select data fields, apply filters, define groupings and sorting, perform calculations, and configure parameters and output formats. The system shall also allow users to save, share, and designate ad hoc reports as favorites for future use. | ||
| GT.38 | The system shall have the ability to support configurable dashboards that display role-based metrics, trends, exceptions, workloads, due dates, alerts, and key performance indicators. | ||
| GT.39 | The system shall have the ability to support scheduled report generation and distribution by email, secure link, dashboard publication, or export to Town-defined repositories. | ||
| GT.40 | The system shall have the ability to support historical trend reporting and point-in-time reporting for operational, financial, service delivery, audit, compliance, and management analysis. | ||
| GT.41 | The system shall integrate with Microsoft Excel to enable live, refreshable reporting and analytics, allowing authorized users to securely retrieve, filter, and analyze ERP data in Excel with on-demand and scheduled refresh capabilities. | ||
| GT.42 | The system shall have the ability to support payroll compliance with applicable federal, state, and local laws, regulations, and Town-defined policies, including configurable payroll rules, validations, and controls for earnings, deductions, taxes, leave, and overtime, with audit trails and reporting to support compliance monitoring, audit requirements, and consistent payroll processing. | ||
| GT.43 | They system shall have the ability to configure and report against user-defined fields. | ||
| User Experience, Accessibility, & Mobile | |||
| GT.44 | The system shall provide a consistent and intuitive user interface across proposed modules to promote ease of use, reduce training needs, and simplify system administration. | ||
| GT.45 | The system shall have the ability to support partial, wildcard, and keyword search across key records, including names, IDs, addresses, parcels, assets, permits, vendors, employees, projects, and other Town-defined records. | ||
| GT.46 | The system shall have the ability to support pre-filled fields, dropdowns, lookup lists, field-level help, tooltips, and data validation to reduce duplicate entry and improve data quality. | ||
| GT.47 | The system shall comply with ADA accessibility expectations and WCAG 2.2 AA or current applicable accessibility standards for internal and public-facing functionality. | ||
| GT.49 | The system shall have the ability to support mobile access through browser-based responsive design, native mobile applications, or both, based on the proposed solution and user role. | ||
| Permitting and Inspections | |||
| PERM.1 | The system shall have the ability to support end-to-end permitting and inspections processes within an integrated community development system, including building permits, trade permits, land use permits, sign permits, Public Works Engineering permits, electronic plan review, inspections, contractor licensing, public portal activity, fees, payments, certificates, and related records. | ||
| PERM.2 | The system shall have the ability to support configurable permitting and inspection workflows, including application intake, completeness review, plan review routing, permit issuance, inspection scheduling, inspection results, correction cycles, approvals, closeout, and status tracking based on Town-defined permit types and business rules. | ||
| PERM.3 | The system shall have the ability to support integration among permitting, inspections, planning and zoning, electronic plan review, code enforcement, contractor licensing, public portal, GIS, fees, cashiering, payment processing, document management (e.g. Laserfiche), and financial systems. | ||
| PERM.4 | The system shall have the ability to support role-based access for permitting and inspections users, including permit technicians, building officials, plan examiners, inspectors, Public Works Engineering reviewers, external agencies, applicants, contractors, consultants, and other Town-defined user groups. | ||
| PERM.5 | The system shall have the ability to support audit trails for permitting and inspection records, including application intake, field updates, workflow changes, review assignments, comments, status changes, approvals, fees, payments, inspections, documents, certificates, and user activity. | ||
| PERM.6 | The system shall have the ability to support online applicant and contractor self-service, including account registration, permit application submission, document upload, fee payment, inspection requests, application and permit status, review comments, correction responses, permit history, payment history, and certificate access. | ||
| PERM.7 | The system shall have the ability to support contractor registration and license management, including contractor master records, state license documentation, insurance documentation, expiration dates, renewal alerts, restrictions, and validation of active contractor status before permit acceptance or issuance. | ||
| PERM.8 | The system shall have the ability to support configurable permit application intake by permit type, including required fields, required submittals, applicant information, contractor information, job value, project cost, valuation, parcel/address information, reviews, inspection sequencing, and other Town-defined data requirements. | ||
| PERM.9 | The system shall have the ability to support address, parcel, legal description, subdivision, and property history tracking for permit records, including the ability to search and report by address, parcel, map/tax lot, record number, legal description, contractor, applicant, permit type, and project or master development record. | ||
| PERM.10 | The system shall have the ability to support permit and inspection relationships with planning records, master development projects, child permits, associated permits, code cases, licenses, plan review records, fees, inspections, conditions, and documents. | ||
| PERM.11 | The system shall have the ability to support configurable plan review routing based on permit type, type of work, project scope, discipline, location, valuation, contractor type, and other Town-defined criteria, including the ability to add or remove review steps and inspections during the permit lifecycle. | ||
| PERM.12 | The system shall have the ability to support internal and external review participation, including review assignments, due dates, comments, correction items, markups, applicant responses, review cycle tracking, and secure access for external agencies and third-party reviewers such as fire districts, school districts, utilities, and other Town-defined reviewers. | ||
| PERM.13 | The system shall have the ability to support electronic plan review integration or embedded electronic plan review functionality, including plan markup, comment management, resubmittal tracking, version control, approved plan set identification, and synchronization of comments and marked-up plans with the permit record. | ||
| PERM.14 | The system shall have the ability to support review cycle controls, including resubmittal tracking, reassignment of reviews upon resubmittal, status changes, reviewer notifications, applicant notifications, and measurement of time with Town staff versus time with applicant. | ||
| PERM.15 | The system shall have the ability to support GIS and parcel integration to validate addresses, associate permits with location attributes, identify zoning or floodplain considerations, display property attributes, and trigger required reviews, restrictions, alerts, calculations, or workflow steps based on location data. | ||
| PERM.16 | The system shall have the ability to restrict, flag, or route permit application types based on conditions associated with a geographic area, subdivision, development agreement, planning approval, utility capacity, floodplain status, or other Town-defined conditions. | ||
| PERM.17 | The system shall have the ability to support automated notifications, alerts, and reminders for permitting and inspection events, including incomplete applications, fees due, review assignments, revisions required, resubmittals received, inspection requests, inspection results, expiring permits, certificates, and closeout actions. | ||
| PERM.18 | The system shall have the ability to support fee calculation, invoicing, payment tracking, refunds or adjustments, and validation that required fees and sign-offs are complete before permit issuance, inspection approval, certificate of occupancy, temporary certificate of occupancy, or permit closeout, with authorized override tracking. | ||
| PERM.19 | The system shall have the ability to support issuance and tracking of permits, certificates of occupancy, temporary certificates of occupancy, completion certificates, and other Town-defined permit documents, including conditions, expiration dates, reinspection dates, required sign-offs, and applicant access through the public portal. | ||
| PERM.20 | The system shall have the ability to support inspection scheduling through staff and public portal workflows, including applicant-requested inspections, comments or notes on inspection requests, Town-defined scheduling windows, inspector assignment, calendar views, route optimization or geographic grouping where available, and inspection workload management. | ||
| PERM.21 | The system shall have the ability to support mobile inspection functionality for field staff using tablets, laptops, or mobile devices, including offline or low-connectivity access where available, inspection checklists, results entry, correction notes, photos, documents, signatures, and synchronization to the permit record. | ||
| PERM.22 | The system shall have the ability to support inspection sequencing, recurring inspection activities, reinspection scheduling, correction tracking, failed inspection follow-up, inspection history, and closeout requirements by permit type, including Building and Public Works Engineering permit scenarios. | ||
| PERM.23 | The system shall have the ability to support document and submittal management for permitting and inspection records, including required submittal checklists, batch uploads/deletion, document categorization, version history, native preview, approved plan set identification, certificate storage, inspection attachments, and correspondence. | ||
| PERM.24 | The system shall have the ability to support dashboards and reports for permitting and inspections, including permit volume, application status, review status, inspection workload, inspection results, cycle times, revisions required, expiring permits, open permits, issued certificates, external review activity, and department-level performance measures. | ||
| PERM.25 | The system shall have the ability to support configurable data exports, standard reports, and ad hoc reporting for permitting, inspections, public transparency, workload monitoring, compliance tracking, management reporting, and future RFP evaluation or implementation planning needs. | ||
| GIS Integration | |||
| GIS.1 | The system shall have the ability to support GIS and property data integration for community development processes, including planning, permitting, inspections, code enforcement, public portal, electronic plan review, and reporting. | ||
| GIS.2 | The system shall have the ability to support integration with the Town’s Esri environment and GIS web services, including ArcGIS Server, ArcGIS Online, ArcGIS Enterprise, enterprise geodatabases, and Town-defined spatial layers such as parcels, addresses, zoning, overlays, floodplain, subdivisions, right-of-way, easements, utilities, and infrastructure. | ||
| GIS.3 | The system shall have the ability to associate community development records with one or more parcels, addresses, map features, subdivisions, projects, or geographic areas and validate parcel or address information during intake, permit entry, case creation, inspection scheduling, and public portal submission. | ||
| GIS.4 | The system shall have the ability to support map-based search, inquiry, and location history for parcels, addresses, projects, permits, planning applications, inspections, code enforcement cases, licenses, fees, documents, correspondence, and related records. | ||
| GIS.5 | The system shall have the ability to support GIS-driven workflow routing and automated triggers based on location attributes, including zoning district, overlay district, floodplain status, subdivision, proximity, jurisdictional boundary, or other Town-defined spatial criteria. | ||
| GIS.6 | The system shall have the ability to support location-based validations and calculations using GIS and application data, including parcel area, lot coverage, setbacks, valuation, improvement area, frontage, distance, and other Town-defined review criteria. | ||
| GIS.7 | The system shall have the ability to support tracking and enforcement of geographic conditions or development limitations, including subdivision conditions, permit caps, phasing restrictions, and other location-based requirements carried forward from planning to permitting and inspections. | ||
| GIS.8 | The system shall have the ability to support map-based assignment and routing of inspections, code enforcement cases, and field activities by district, zone, geography, workload, proximity, or other Town-defined criteria, including the ability to reroute based on changes to the inspection load (e.g. cancellations or additional inspections). | ||
| GIS.9 | The system shall have the ability to support mobile map access and location-based field updates for inspectors, code enforcement staff, and other field users, including assigned work, parcel details, related records, GIS layers, directions, photos, notes, results, coordinates, and asset references. | ||
| GIS.10 | The system shall have the ability to support configurable display of GIS layers within staff-facing and public-facing maps, with role-based visibility for sensitive, internal, draft, or restricted information. | ||
| GIS.11 | The system shall have the ability to support public portal map functionality that allows applicants, residents, and other authorized users to search properties, view applicable location information, and initiate applications, permits, or requests from a selected parcel or address. | ||
| GIS.12 | The system shall have the ability to support integration, data exchange, synchronization, or scheduled refresh with external GIS and property data sources, including Douglas County parcel data, GeoHub data, state datasets, and other Town-designated authoritative sources. | ||
| GIS.13 | The system shall have the ability to support data quality controls for GIS-related records, including duplicate address detection, invalid parcel alerts, missing spatial reference alerts, and exception reporting for records that cannot be matched to GIS data. | ||
| GIS.14 | The system shall have the ability to support exports, APIs, web services, or other secure data exchange methods to share community development activity with GIS, asset management, public safety, reporting, and other Town-defined systems. | ||
| GIS.15 | The system shall have the ability to support historical lookup and reporting for converted GIS-linked records from legacy systems, including TRAKiT/eTRAKiT records associated with parcels, addresses, permits, planning applications, inspections, and code enforcement cases. | ||
| GIS.16 | The system shall have the ability to support configurable GIS dashboards and reports, including application activity by geography, permit volume by area, inspection workload, code enforcement hotspots, development trends, and spatial workload analysis. | ||
| GIS.17 | The system shall have the ability to support role-based security and audit trails for GIS-linked community development records, including changes to parcel associations, address links, map-based routing, GIS-triggered conditions, and location-based workflow decisions. | ||
| GIS.18 | The system shall have the ability to support documentation and administration of GIS integration configuration, including source layers, refresh frequency, field mappings, ownership, error handling, and dependencies for ongoing support. | ||
| GIS.19 | The system shall have the ability to support a “near me” search capability allowing users to locate related system records based on proximity to a selected address, parcel, or map location, including access to active and historical records such as permits, inspections, planning applications, and code enforcement cases. | ||
| GIS.20 | The system shall have the ability to support field-based GIS interaction, including the ability for authorized users to select map features (e.g., parcel, address, asset, or location) and initiate system records such as inspections, code enforcement cases, permits, or service requests directly from the GIS interface, with linkage to the selected feature. | ||
| Planning and Zoning | |||
| PLAN.1 | The system shall have the ability to support end-to-end planning and zoning processes within an integrated community development system, including planning applications, zoning reviews, plats, site plans, annexations, rezonings, conditional uses, temporary uses, sign permits, public portal activity, electronic plan review, permitting, inspections, code enforcement, and related records. | ||
| PLAN.2 | The system shall have the ability to support configurable planning and zoning workflows, including routing, approvals, task assignments, due dates, escalations, notifications, and status tracking based on Town-defined application types and business rules. | ||
| PLAN.3 | The system shall have the ability to support role-based access for planning and zoning users, including Town staff, external reviewers, applicants, contractors, consultants, boards and commissions users, and other Town-defined user groups. | ||
| PLAN.4 | The system shall have the ability to support audit trails for planning and zoning records, including application intake, workflow changes, review comments, approvals, corrections, status changes, fees, documents, and user activity. | ||
| PLAN.5 | The system shall have the ability to support master project records that link related planning applications, permits, inspections, code enforcement cases, licenses, electronic plan review records, documents, fees, conditions, and correspondence. | ||
| PLAN.6 | The system shall have the ability to associate multiple applications or records with a project at any point in the process to support tracking of subdivisions, developments, phased projects, and related permitting activity. | ||
| PLAN.7 | The system shall have the ability to support online applicant self-service for planning and zoning applications, including application submission, document upload, fee payment, application status, task status, review comments, correction responses, application history, and payment history. | ||
| PLAN.8 | The system shall have the ability to support staff dashboards showing assigned tasks, due dates, workload, application status, review status, pending actions, overdue items, and upcoming deadlines. | ||
| PLAN.9 | The system shall have the ability to support internal and external notifications based on Town-defined workflow events, including application submission, completeness review, reviewer assignment, fee payment, corrections requested, resubmittal received, approval, denial, expiration, and closure. | ||
| PLAN.10 | The system shall have the ability to support external reviewer participation, including secure access, review assignments, comment entry, markup access, due dates, and review status tracking. | ||
| PLAN.11 | The system shall have the ability to control when review comments, markups, correction items, and applicant-facing correspondence become visible to applicants or the public based on Town-defined workflow steps. | ||
| PLAN.12 | The system shall have the ability to support configurable review cycles, including completeness review, internal review, external review, applicant corrections, resubmittals, final review, approval, and closeout. | ||
| PLAN.13 | The system shall have the ability to support tracking of time spent in each planning review step, including days with Town staff, days with applicant, resubmittal cycle time, overdue reviews, and total application processing time. | ||
| PLAN.14 | The system shall have the ability to support default workflow templates for Town-defined planning application types, including the ability to modify routing, reviewers, required submittals, fees, review timelines, and approval steps by application type. | ||
| PLAN.15 | The system shall have the ability to support GIS and parcel integration to associate applications with parcels, addresses, zoning districts, overlays, floodplain status, subdivision boundaries, property attributes, and other Town-defined location data. | ||
| PLAN.16 | The system shall have the ability to trigger workflow steps, alerts, required reviews, calculations, or submittal requirements based on GIS, parcel, zoning, floodplain, overlay, or other location-based attributes. | ||
| PLAN.17 | The system shall have the ability to support location-based calculations and validations using application and GIS data, including lot coverage, setbacks, parcel area, valuation, zoning criteria, and other Town-defined review rules. | ||
| PLAN.18 | The system shall have the ability to support tracking of planning conditions, development obligations, subdivision limits, approval stipulations, and other project-specific requirements that must be carried forward to permitting, inspections, or future development activity. | ||
| PLAN.19 | The system shall have the ability to support document and submittal management for planning records, including required submittal checklists, batch uploads/deletion, multi-record document association, document categorization, version history, native preview, and approved plan set identification. | ||
| PLAN.20 | The system shall have the ability to support electronic plan review integration or embedded electronic plan review functionality, including plan markup, comment management, resubmittal tracking, version comparison, approved plan sets, and applicant access to correction comments. | ||
| PLAN.21 | The system shall have the ability to support fee assessment, invoicing, payment tracking, refunds or adjustments, and integration with cashiering, payment processing, and financial systems for planning and zoning applications. | ||
| PLAN.22 | The system shall have the ability to support agenda, meeting, and board and commission coordination for planning-related items, including public hearing dates, noticing requirements, staff reports, meeting outcomes, conditions of approval, and related documents. | ||
| PLAN.23 | The system shall have the ability to support correspondence and communication tracking for planning and zoning records, including applicant messages, public comments, staff notes, email history, notices, generated letters, and document attachments. | ||
| PLAN.24 | The system shall have the ability to support reporting and dashboards for planning and zoning activity, including application volume, review cycle times, reviewer workload, aging applications, approval and denial outcomes, resubmittal counts, open conditions, and public portal activity. | ||
| PLAN.25 | The system shall have the ability to support data export and reporting for Town-defined planning, zoning, development review, public transparency, performance measurement, and management reporting needs. | ||
| Electronic Plan Review | |||
| EPR.1 | The system shall have the ability to support end-to-end electronic plan review processes within an integrated community development system, including planning applications, permits, resubmittals, comments, markups, approved plan sets, inspections, and related records. | ||
| EPR.2 | The system shall have the ability to support configurable electronic plan review workflows, including intake, completeness review, discipline review, applicant corrections, resubmittal, approval, and closeout based on Town-defined application or permit types without required vendor support. | ||
| EPR.3 | The system shall have the ability to support role-based access for electronic plan review users, including Town staff, applicants, contractors, design professionals, consultants, external agencies, third-party reviewers, inspectors, and other Town-defined user groups. | ||
| EPR.4 | The system shall have the ability to support audit trails for electronic plan review records, including document uploads, file version changes, review assignments, comments, markups, status changes, approvals, applicant responses, and user activity. | ||
| EPR.5 | The system shall have the ability to support online plan submittal through the public portal, including required document checklists, file naming standards, file type and size validation, batch upload, and applicant confirmation. | ||
| EPR.6 | The system shall have the ability to support document organization for plan review records, including submittal categories, discipline-specific files, supporting documents, version history, native preview, and identification of the current approved plan set. | ||
| EPR.7 | The system shall have the ability to support electronic markup and comment tools, including review comments, correction items, stamps, annotations, attachments, response tracking, and status by reviewer or discipline. | ||
| EPR.8 | The system shall have the ability to support comment consolidation and correction management, including the ability to compile comments by discipline, remove duplicate comments, assign correction responsibility, track applicant responses, and carry unresolved comments into subsequent review cycles. | ||
| EPR.9 | The system shall have the ability to support plan version control and resubmittal tracking, including comparison between submitted versions, identification of revised sheets or documents, preservation of prior versions, and linkage of comments to the applicable plan version. | ||
| EPR.10 | The system shall have the ability to support internal and external review participation, including secure reviewer access, review assignments, due dates, discipline-specific routing, third-party reviewer comments, and review status tracking. | ||
| EPR.11 | The system shall have the ability to control when review comments, markups, correction items, and approved documents become visible to applicants, external reviewers, inspectors, or the public based on Town-defined workflow steps. | ||
| EPR.12 | The system shall have the ability to support real-time status tracking, automated notifications and reminders for plan review activity, including reviewer assignments, pending reviews, overdue reviews, applicant corrections, resubmittals received, approvals, denials, and expired or inactive reviews. | ||
| EPR.13 | The system shall have the ability to support integration or data exchange with permitting, planning, inspections, code enforcement, licensing, fees and payments, and document management records to maintain consistent project and application information. | ||
| EPR.14 | The system shall have the ability to support review holds, conditions, and approval requirements, including required sign-offs, unresolved correction items, outstanding fees, missing documents, and other Town-defined conditions before approval or permit issuance. | ||
| EPR.15 | The system shall have the ability to support creation, storage, and distribution of approved plan sets, including approval stamps, approval dates, reviewer information, conditions of approval, and controlled access for applicants, staff, and inspectors. | ||
| EPR.16 | The system shall have the ability to support inspector access to approved plans, documents, conditions, and plan review comments from field-capable devices, including mobile or browser-based access where applicable. | ||
| EPR.17 | The system shall have the ability to support migration or lookup of historical electronic plan review records, including legacy plans, comments, markups, approved documents, and related records where available. | ||
| EPR.18 | The system shall have the ability to support secure retention, search, export, and reporting of electronic plan review documents and metadata in accordance with Town-defined records retention, public records, and audit requirements. | ||
| Code Enforcement | |||
| CODE.1 | The system shall have the ability to support end-to-end code enforcement processes within an integrated community development system, including complaint intake, case management, inspections, notices, violations, fees, abatements, public portal activity, permitting, licensing, GIS/property records, and related documentation. | ||
| CODE.2 | The system shall have the ability to support configurable code enforcement workflows, including case intake, assignment, inspections, notices, reinspection, escalation, compliance tracking, abatement, closure, routing, due dates, and notifications based on Town-defined case types and business rules. | ||
| CODE.3 | The system shall have the ability to support role-based access for code enforcement users, including code staff, supervisors, inspectors, internal departments, external users, and other Town-defined user groups. | ||
| CODE.4 | The system shall have the ability to support audit trails for code enforcement records, including complaint intake, case creation, assignments, inspections, notes, photos, notices, fees, status changes, correspondence, user activity, and record changes. | ||
| CODE.5 | The system shall have the ability to support public portal complaint intake, including resident-submitted complaints, anonymous complaint options configurable by the Town, attachments, contact information, location details, complaint category, and automated confirmation where appropriate. | ||
| CODE.6 | The system shall have the ability to support staff-entered complaints and internal referrals, including the ability to route complaints to the appropriate department, program area, or reviewer based on location, case type, violation type, or Town-defined business rules. | ||
| CODE.7 | The system shall have the ability to support configurable case types, violation types, templates, default actions, inspection steps, notice requirements, compliance timelines, and closure criteria for Town-defined code enforcement processes. | ||
| CODE.8 | The system shall have the ability to support tracking of case status and history, including status dates, case type, case source, proactive/reactive/internal designation, assigned staff, related inspections, related violations, and closure outcome. | ||
| CODE.9 | The system shall have the ability to support systemwide case notes and correspondence tracking, including internal notes, public-facing notes, applicant or resident communications, staff comments, generated letters, and configurable visibility controls. | ||
| CODE.10 | The system shall have the ability to support ordinance and violation reference management, including the ability to import, maintain, search, and reference Town ordinances, zoning regulations, code sections, standard language, and authorized user-defined text in notices and letters. | ||
| CODE.11 | The system shall have the ability to support generation of code enforcement notices, violation letters, correction notices, compliance letters, and other Town-defined correspondence, including the ability to include multiple violations for a single property or case. | ||
| CODE.12 | The system shall have the ability to support property, parcel, address, and premises history searches, including the ability to view related code cases, permits, inspections, licenses, planning records, contacts, documents, and prior enforcement activity for a selected location. | ||
| CODE.13 | The system shall have the ability to support GIS and address integration for code enforcement, including map-based case creation, parcel/address validation, geographic assignment, case location display, and spatial reporting by area, district, subdivision, or other Town-defined geography. | ||
| CODE.14 | The system shall have the ability to support code enforcement functionality in both connected and offline environments, including the ability for field users to access case information, capture notes, record violations, take photos, and update case status without an active connection, with automatic synchronization to the central system once connectivity is restored. | ||
| CODE.15 | The system shall have the ability to support photo, document, and evidence management for code enforcement cases, including upload, categorization, date/time capture, user attribution, mobile capture, retention, and association to inspections, violations, notices, and case records. | ||
| CODE.16 | The system shall have the ability to support inspection assignment and reinspection tracking for code enforcement, including staff workload, inspection due dates, follow-up inspections, compliance deadlines, and overdue inspection alerts. | ||
| CODE.17 | The system shall have the ability to support administrative fees, fines, abatement charges, invoices, payment tracking, adjustments, and collections activity for code enforcement cases, including integration with cashiering, accounts receivable, payment processing, or financial systems. | ||
| CODE.18 | The system shall have the ability to support abatement tracking, including authorization, contractor/vendor involvement where applicable, work performed, costs, invoices, supporting documentation, status, and final collection or cost recovery activity. | ||
| CODE.19 | The system shall have the ability to support integration and cross-reference between code enforcement and planning, permitting, inspections, licensing, contractor records, public portal, electronic plan review, fees and payments, GIS, and document management records. | ||
| CODE.20 | The system shall have the ability to support configurable dashboards and reports for code enforcement activity, including open cases, aging cases, cases by type/source/status/location, inspection workload, compliance rates, repeat properties, abatement activity, fines/fees, and staff performance measures. | ||
| CODE.21 | The system shall have the ability to support automated alerts and reminders for pending case actions, overdue inspections, compliance deadlines, escalation points, unpaid fines or fees, unresolved complaints, and upcoming closure or abatement steps. | ||
| CODE.22 | The system shall have the ability to convert or link code enforcement activity to related permits, inspections, licenses, planning applications, or other Town-defined records when a violation requires follow-up work or formal approval. | ||
| CODE.23 | The system shall have the ability to support data export for code enforcement records, including user-defined filters, report templates, public records support, management reporting, and ad hoc analysis. | ||
| CODE.24 | The system shall have the ability to support configurable retention, search, and retrieval of historical code enforcement records, including migrated records from legacy systems, inactive cases, closed cases, notices, photos, documents, and related property history. | ||
| CODE.25 | The system shall have the ability to support user-friendly interfaces for code enforcement staff, supervisors, mobile users, and public portal users, including clear navigation, searchable records, configurable views, and access to assigned work and related case information. | ||
| Public Portal | |||
| PORT.1 | The system shall have the ability to support a public self-service portal for community development services, including planning applications, permits, inspections, code enforcement complaints, electronic plan review, licensing, fees, payments, and related records. | ||
| PORT.2 | The system shall have the ability to support role-based portal access for applicants, property owners, contractors, design professionals, residents, external reviewers, and other Town-defined user groups. | ||
| PORT.3 | The system shall have the ability to support account registration, login, profile management, contact information maintenance, and association of portal users with businesses, contractors, properties, projects, applications, permits, and cases. | ||
| PORT.4 | The system shall have the ability to support online submission of planning applications, permit applications, inspection requests, code complaints, license applications, documents, plans, forms, and other Town-defined submittals. | ||
| PORT.5 | The system shall have the ability to guide users through application intake using configurable forms, required fields, conditional questions, document checklists, instructions, validations, and business rules based on application type. | ||
| PORT.6 | The system shall have the ability to support applicant dashboards showing application status, permit status, inspection status, plan review status, assigned tasks, correction items, fee balances, payment history, submittal history, and related communications. | ||
| PORT.7 | The system shall have the ability to support online payment of application fees, permit fees, inspection fees, reinspection fees, code enforcement fees, license fees, deposits, and other Town-defined charges through integration with the Town’s payment processor or financial system. | ||
| PORT.8 | The system shall have the ability to support automated portal notifications and reminders for application submission, completeness review, payment due, review comments, correction requests, resubmittals, inspection scheduling, inspection results, approvals, expirations, and other Town-defined events. | ||
| PORT.9 | The system shall have the ability to support secure two-way communication between Town staff and portal users, including messages, comments, correction responses, attachments, status updates, and communication history tied to the related record. | ||
| PORT.10 | The system shall have the ability to support applicant response to plan review comments, permit corrections, inspection corrections, and code enforcement notices through the portal, including document upload, comment response, and resubmittal tracking. | ||
| PORT.11 | The system shall have the ability to support portal-based document upload, download, preview, version tracking, file validation, approved document identification, and association of documents to projects, applications, permits, inspections, and cases. | ||
| PORT.12 | The system shall have the ability to control which records, comments, documents, markups, inspection results, notices, and internal notes are visible to portal users or the public based on Town-defined security and workflow rules. | ||
| PORT.13 | The system shall have the ability to support contractor and business interactions through the portal, including license or registration status, permit associations, insurance or documentation requirements, renewal reminders, and restrictions when required credentials are missing or expired. | ||
| PORT.14 | The system shall have the ability to support public search and inquiry for Town-defined records, including permits, planning applications, code cases, inspections, licenses, addresses, parcels, project records, and related public information. | ||
| PORT.15 | The system shall have the ability to support mobile-responsive portal access for applicants, contractors, residents, and external reviewers using common browsers and devices without requiring separate Town-managed software. | ||
| PORT.16 | The system shall have the ability to support external reviewer access through the portal, including review assignments, due dates, document access, comment entry, markup access, response tracking, and status visibility. | ||
| PORT.17 | The system shall have the ability to support portal analytics and reporting, including user activity, application submissions, payment activity, document submissions, incomplete applications, inspection requests, complaint submissions, response times, and public search activity. | ||
| PORT.18 | The system shall have the ability to support audit trails for portal activity, including submissions, payments, uploads, downloads, comments, messages, status changes, user profile changes, and public or applicant access events. | ||
| PORT.19 | The system shall have the ability to support integration with the Town’s website and related systems, including community development modules, payment processing, document management, GIS, electronic plan review, licensing, inspections, and financial systems. |
&"Arial,Bold"&12Request for Information:&"Arial,Regular" ERP and Community Development Software
&"Arial,Bold"&12Request for Information:&"Arial,Regular" ERP and Community Development Software
&"Arial,Bold"&12Request for Information:&"Arial,Regular" ERP and Community Development Software
&"Arial,Bold"&14Town of Parker &"Arial,Regular"Request for Information (RFI) Workbook
&"Arial,Regular"&10BerryDunn &"Arial,Regular"&10April XX, 2013
&"Arial,Regular"&10BerryDunn &"Arial,Regular"&10April XX, 2013
&"Arial,Regular"&10BerryDunn &"Arial,Regular"&10April XX, 2013
&…
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 .