CarePortal Church Needs Case Study

Discovery and Design

Global Orphan had previously worked with Code Koalas on several Laravel projects, completing and enhancing their CarePortal app which allowed for thousands of churches, communities, agencies and users to help meet the needs of families and foster children across the country.

Coming off of these successful launches, Global Orphan began to study bottlenecks for system adoption, also taking into account what potential features could help churches engage with their own community and congregation in a more organic way. Since successful system adoption in new markets relies both on new agencies and churches to simultaneously adopt CarePortal, we focused on finding a way to let churches start to use CarePortal prior to agency adoption. It was this vision that prompted development of the Church Needs functionality.

The new Church Needs feature implementation was simple: enable internal needs from within a congregation to be submitted, communicating those needs to their congregation, and enabling members to meet those needs. When needs aren't met by a church's own members, they have the ability to escalate those needs into the community. This entire workflow mimics the agency/request workflow on a smaller scale, therefore enabling church leadership to take care of their congregation better as well as immediately familiarizing church responders with full system functionality, providing an immediate and free benefit to any church using CarePortal.

Since we completed the previous iterations of the CarePortal Laravel app, our team was well versed in the functionality of the system. We met with Global Orphan to plan out the project, spending time on discovery to ensure that every workflow, data model, role, and action was once again accounted for. This was an absolutely necessary step for the project, ensuring that all components remained operational, given that the existing app had a massive codebase and functionality. After discovery was complete, we met again to discuss our outline, gathered feedback, and signed a formal work agreement to begin work on the application.

Buildout

Through the discovery, we planned the buildout and outlined every update that needed to be deployed, ensuring that new functionality would maintain and compliment existing workflows. We organized all work according to role and data model, so that specific models and roles that contained similar functionality would be tackled at the same time. We also implemented new polymorphic relationships in the app, enabling the new church needs to function exactly like current agency requests do, thus cutting down on extra work down the road. Work was broken out by ticket and assigned in 2-week sprints, with client meetings occurring weekly to showcase progress and discuss new functionality.

Our first step in development was creating the infrastructure allowing churches to enable church needs. We then expanded existing functionality to automatically convert any member accounts to full system users when Church Needs was enabled. The next step our developers took was to convert the existing agency request relationships and functionality throughout the system to a polymorphic relationship, allowing future variations of agency requests like the new church needs to work exactly as expected, with all functionality intact.

Since this impacted important system functionality, our developers spent a considerable amount of time working through the existing workflows to ensure that the entire system continued to function properly. We also consolidated code throughout the system into new single use action classes. This consolidation took a myriad of CRUD actions implementations throughout the app and moved them into single universal functions. Making these changes both cut down on development time, and also enabled a more stable system for the future.

Lastly, we built out new functionality allowing churches to escalate unmet needs to their own community through the CarePortal system. Emails were tweaked and logic was written to correctly integrate the new needs workflow.

Part of the Church Needs scope of work was also retheming the main church engagement page. Previously, the page served as a simple informational landing page for church members. Functionality was limited, and unimportant details were featured prominently. With the redesign, we placed the most important details front and center, allowing users to immediately feel engaged with their churches own needs and requests. We also took existing user functionality from our CareCenter integration, allowing anyone to easily interact and fulfill the need.

Throughout the buildout process, our project managers QA’d features and functionality on the website as they were created and pushed to our development server. We regularly handed off sections of the site to the client for QA, ensuring that everyone had tested and signed off on the style changes prior to launch. Once features were verified, they were pushed to a second server in a live testing environment for an additional round of testing. We also created pipeline tests that ran prior to every code merge, ensuring that all new functionality wouldn’t affect existing workflows and procedures.

Launch

The new Church Needs functionality of the CarePortal app delivers a fully functional experience geared towards allowing churches to interact and engage their own congregation better. Adoption of the Church Needs functionality provides users immediate familiarity with the CarePortal agency request functionality, while removing vital barriers to adoption in new markets. New roles were created and functionality was expanded across the board, ensuring that people in need get help in a quick and timely manner. Churches and individuals are more engaged and able to create a better community for everyone. CarePortals new app elevates their brand, positioning them as a unique and important player in communities across the country. Countless family's lives will be improved daily through their efforts.