Online Portal and Application Build for Early Years RFP Updates and Questions

Only entities officially incorporated, headquartered, and operating within the USA are eligible to submit a proposal. International entities without a registered subsidiary may not participate.  Early Years reserves the right to request official registration documentation prior to awarding the contract.

Remote work is acceptable.

Yes.

All proposals will be reviewed by a committee of Early Years staff.

Please see the attached document for more details related to the selection criteria. HERE

After making our final decision, we would like to be able to sign a contract within a month to begin this work.

Itemization by phase is ideal. Any additional itemization within each phase is optional, but all quotes should include any third-party licensing, document-storage costs, messaging/notification costs, and any anticipated ongoing operating expenses.

No, we don’t have a template.

No access will be granted prior to the proposal deadline, but it should be noted that the partially completed portals for both applicants and approved contacts are not functional or in use at this time.  Prior Salesforce assets can be used in the presented recommended solution.

Early Years already holds licenses for Salesforce Education Cloud as well as licensing needed for Community logins. You should include the number of Salesforce licenses recommended for your proposed solution. Currently, for cost purposes, we are licensed at much lower numbers than will be needed at the time of launch of a Salesforce solution.

There is no specific budget in mind for this project, but all bids should be competitive.

We expect this project to take anywhere from 6 to 12 months to complete. There are no specific go-live dates in mind for any of the phases related to our program cycles or launch cadence.

This project will be assigned an Early Years Project Manager who will be the primary contact for communications and coordination of any technical or programmatic subject matter experts needed throughout the process.

Our agency employs FileMaker Pro, Laravel and Vue developers that will be available to help support this work and collaborate with as it progresses.

A combination of live, recorded and documentation would be ideal.

Early Years will provide a branding guide and branding toolkit.

We are open to hear any suggestions you think will meet the needs of this project.

We expect this portal experience to technically be a separate tool, but have the same look and feel as the rest of our online presence.

We anticipate this would be a collaborative activity.

Transition the application process to paperless, and streamlining the process.

This level of detail will be discussed more during the discovery phase.

We contracted with a vendor to build what currently exists in Salesforce for our portal interfaces. The biggest limitation related to these portals is the Approved Contact functionality – we don’t believe the proper many-to-many structure is in place. No other department within our agency uses Salesforce – the recent (incomplete) build was our first experience with it. The high ongoing licensing costs for using Salesforce are something we are evaluating, especially since we have limited internal expertise for supporting Salesforce.

Participants are often concerned about their status within the program and a portal will allow for increased transparency and easier communication with program staff.

We want a turn-key solution that will be scalable and that we can maintain going forward.

This new build does not need to connect with anything beyond the backend FileMaker Pro database that has already been mentioned.

Applications and program participation are ongoing throughout the year.

We use AWS but are open to other platforms.

We currently use Google Workspace and AWS SES.

Since we collect SSN and other PII, the solution must meet or exceed encryption standards for HIPAA and PII requirements. WCAG (Level A as a minimum) accessibility compliance is preferred.

This should be supported in all modern browsers and mobile devices.

Early Years staff currently use SSO. Applicants and Approved Contacts should have an MFA available via code sent by text or email.

Any public facing portals would be subject to the same privacy policy as our Early Years website.

We feel 15 minutes is a good inactivity session timeout.

Notifications sent via SMS and/or email are acceptable. Early Years will own the email domain.

Our national partners maintain their own FileMaker databases within their own network environments. We have access to those systems for support purposes but they are not connected to each other.

Yes, each national partner will have their own set of eligibility criteria, branding and workflows. This system will ideally be flexible enough to allow for that.

We are open to evaluating any cost-effective technology stack proposed, but the ability to continue supporting it internally will be important. We currently have multiple apps utilizing Laravel/Vue. Our internal FileMaker team does not have experience developing or supporting web-based apps in FileMaker, but would be open to exploring that if it could meet the needs of this project.

We will provide access so we can coordinate production deployment.

We use a variety of server environments throughout the agency and would be open to hearing recommendations based on proposed solutions.

Our current FileMaker system is a legacy system. It is made of hundreds of fields in multiple tables. We expect to develop this collaboratively.

A balance between cost, timing and risk will be factored into our decision.

The Salesforce portal we currently have represents different functionality from what our FileMaker backend does.

Our current FileMaker database is used to manage all aspects of our program. Staff manually enter application data that is received via mail or email. The system tracks employment history, educational levels and changes, and does complex calculations based on multiple factors for anticipated payments, adjusted payments and actual payments. This system is also responsible for a variety of complex reporting.

We are current with FMP versions. We do not have a FileMaker Data API – that would need to be developed. We expect all two way communication actions: Read/write, create, update, etc.

On-premise.

We can provide test environments and expect to be heavily involved in testing throughout all phases.

Early Years staff and admin will manage internal tasks in FileMaker Pro.

Developers will be available to create/modify layouts as needed.

Our goal is to automate as much as possible.

Our FileMaker system is tightly coupled in many areas. That being said, we are willing to consider some restructuring to increase efficiency.

Only application submissions since employment confirmations are meant for Approved Contacts and they are part of Phase 4.

No, it has not.

The FileMaker backend will be the source of truth.

We expect to have an API developed to help with integration. We do not anticipate needing real-time data integration. A scheduled batch will likely meet our needs for everything included in the integration (applications, payments, confirmations).

We anticipate sharing relatively basic payment data including date paid and payment amount. No additional security or encryption would be needed.

WAGE$ and STEP$ share a common FileMaker instance. TEACH has its own, independent FileMaker instance.

Early Years has a site licence for all users, as well as a production and development premise Filemaker servers.  Additional development licenses could be provided.

This should be fully production-ready for all active users.

Yes, these should all be available from day one of this phase going live.

While we currently use Sharepoint, we are open to a different approach.

Early Years has a documentation retention policy.  The documents for this project must be retained for at least 7-8 years.

There is no maximum number of uploads to accompany applications. File types vary (PDF, DOC, DOCX, XLS, XLSX, CSV, PPT, PPTX, RTF, TXT, JPG, PNG, and TIFF, etc…) as do sizes.

A clickable URL would work to connect stored documents to a record in FileMaker.

Being able to view a document via preview or pop-out would be ideal.

We are using SharePoint through Microsoft 365 and we have not configured external web connections.

Documents uploaded into the portal should stay locally stored in that environment until Early Years staff have reviewed and accepted the documentation. At that point it could be stored in Sharepoint.

Once a document has been reviewed by Early Years staff and it is moved to Sharepoint for storage, the portal user does not have to be able to continue to access that original item.

This is not necessary.

Yes, applicants must be able to upload documents outside of an application.

Yes. It would be ideal if some basic data auto filled for subsequent applications to alleviate some of the needed data entry.

Approved Contacts are usually administrators within a child care facility (owner, director, etc.). Some child care facilities will have multiple Approved Contacts designated. Some individual Approved Contacts will be attached to/assigned to multiple child care facilities (such as a group of Head Start locations). There are no maximums in place but anecdotally there usually isn’t more than 20 child care facilities attached to the same Approved Contact

Approved contacts should be able to complete employment verifications (attached to applications), employment confirmations (as part of program participation) as well as send and receive communications from Early Years staff. They should have the ability to send a notification to Early Years staff to let us know of employment changes within their company, but that information should not modify any live data.

We envisioned a single account with role switching capabilities but are open to design suggestions. Designating a particular account as dual-role should be managed through permissions and controlled by Early Years staff.

Approved Contact accounts should be created by Early Years staff to ensure the correct individuals are given this level of access. We would consider a bulk import of accounts at launch.

We do not require hierarchy to be built into Approved Contacts, but if it were there it may open some functionality we could benefit from.

Early Years staff will control the granting of user accounts for approved contacts. We anticipate managing this internally but will need a mechanism to invite that approved individual to create their approved contact user account.

These are the 4 main user roles, although there may be some nuance within a group. For example, we may have a regular Early Years staff user but then a more enhanced Early Years staff user with a few additional functions available (i.e. approvals). Details related to each of these roles can be fully flushed out during discovery.

A program participant can still maintain a portal account even if they no longer participate. This will allow them to apply again or eventually apply to another program.
Approved contacts that are no longer with a facility should have their accounts disabled by Early Years staff.

New applicants can self-register for the portal without Early Year’s approval. No accounts will be created by bulk import at launch.

Early Years staff should be able to complete an application for someone over the phone if they are not able to complete one for whatever reason.

Applications will always be available. We generally expect about 4000 active program participants annually on WAGE$. Once the application is submitted they might log in infrequently or not at all. The STEP$ program is expected to serve about 1800 additional program participants. These individuals will be required to reapply once per year. Approved contacts (approximately 5000) will likely log into the system multiple times throughout the year, but that timing and routine varies depending on how many staff they are confirming and when those confirmations are due. There are about 20-25 Early Years staff (of all levels) who will access the system.

Yes.

Customizable reporting and dashboards should be included in the design.

There is no current predefined structure since online applications would be new to the program. FileMaker is able to easily import CSV and/or Excel files.

We would prefer to have a Spanish application at time of launch.

Early Years will provide translations, we currently have our paper applications in English and Spanish.

Spanish is required for the applicant-facing experience only.

We would be open to this if it’s not cost prohibitive.

It is our intention that internal developers will manage the maintenance of the system, but we may contract with a vendor for larger and/or more specialized support needs.

We don’t have specific guidelines at this time and are open to recommended options.

We anticipate using our own trained support staff to train the rest of the program teams utilizing these systems.

Applications can change year to year. Early Years system admins should be able to add questions/fields, remove questions/fields, change wording on existing questions/fields, rearrange questions/fields, etc. within all forms.

Yes, application structure should be locked in at the point of application creation. Access to fields (to change answers) should be available until the application is submitted.

Ideally, Early Years would be able to configure new programs without outside development support.

WAGE$ and STEP$ each have their own eligibility criteria (which look at things like county and income level). The applications for these programs are similar but not identical, so they will each have their own logic.

Users should be able to save a draft of their application and resume completion later. Once the applicant has finished their portion of the application, it is sent to an approved contact for them to complete the employment verification section. Once this has been done, the application can be considered complete and submitted and will then be reviewed by EY staff.

Yes, both application reviews and employment confirmation reviews will go through a process that requires a variety of status options. Yes, an audit history of those status changes would be required.

Application approval is a multi-level process.

Once an application has been submitted for approval, all application data should be locked (read only) and no longer modifiable by the applicant.

Yes there is conditional logic. A majority are show/hide fields, but there may be instances of multi-condition rules. Some of this is based on the program WAGE$ or STEP$.

Drafts should not expire and configurable trigger reminders are desired.

No data migration for applicants is necessary. This will be a clean slate for new applications only.

Not all new applications will be coming in right away. We do not intend to have a phased roll-out for the applications.

Application fields should allow for all types of fields including, but not limited to: short answer text, long answer text, dropdown, checkbox, radio button, file upload, date picker, electronic signature and conditional fields.

Our current applications for these programs can be found on our website.

It is unlikely that we will be comfortable with AI augmentation replacing manual review until after this new system has been implemented and in use for some time. Similarly, using AI to automatically extract, classify, and validate data from uploads would not be needed at this time.

Yes.

Confirmation records are currently initiated from FileMaker on a monthly basis. This will continue to hold true but once two-way connections are established, they will be sent out via the portal. Approved contacts will have a deadline for finishing the confirmation form (with notifications sent if incomplete) and then once complete will be submitted back to FileMaker for staff review.

A checkbox and attestation is sufficient. An e-signature solution is not required.

This is outside the scope of our normal workflow and is not necessary at this time.

Configurable triggers for all audiences are needed to manage a variety of scenarios. Applicants should get notifications related to incomplete applications, application status changes, etc. Approved contacts should get notifications related to confirmations needed to be completed, confirmation overdue, etc. Early Years staff should get notifications related to applications submitted, new messages from portal users, etc.

Early Years staff (high level users) should have the ability to add, modify and inactivate various communication templates.

Some communication may occur after an applicant has moved on to become a program participant. It would be ideal to be able to tag or reference a particular application within their account, if communication is related to that item.

Yes, both program applicants/participants as well as Early Years staff should be able to attach items to communication messages.

Yes, any messages received from participants should have an indication if they are read or unread, and Early Years staff should be able to archive or escalate issues.

We are open to considering integration with staff email, but don’t know exactly what that might look like or what it might cost.