Learn about answers to frequently asked technical questions.
Please note: This article is intended for all users.
Grow is able to support as many total users as required by the District. Grow auto-scales based on the amount of traffic the site experiences. This architecture can scale up indefinitely to handle any amount of concurrent user load.
What are the technical requirements for running Grow?
Since Grow is a cloud-based platform, it can be accessed using simply an internet connection and does not require any download or installation to run. Grow is compatible with both Windows and OS operating systems, and requires an up-to-date browser. We recommend using Chrome, Firefox, Safari or Microsoft Edge. While Grow might work sporadically in Internet Explorer, Microsoft has ceased making updates to that browser and full operability is not guaranteed. Grow is also compatible with smartphones and tablets. While there is no dedicated Grow app, a mobile version of the platform can be accessed via any mobile browser.
All communication with Grow happens over a secure TLS connection to prevent eavesdropping and tampering. All of Grow's servers are hosted by Google Cloud Platform and are not accessible outside the internal network except via a GCP Load Balancer which handles the TLS communication. All data that Grow stores is encrypted at rest and not accessible outside of the internal GCP network. Interaction with Grow servers is only possible via the Grow application, which uses the OAuth2 protocol to handle user authentication. In addition to the encryption provided by the TLS protocol, all interactions with authenticated users include a short-lived bearer token used to identify users in Grow.
Our cloud-based database, MongoDB, offers continuous backups for all of our data. Backups are taken continuously, ensuring that backup data is at most a few minutes behind the live database. At any time, if needed, Grow can recover the database from any point in the preceding 24 hours, or choose a specific saved snapshot from a timeframe earlier than that. With any unforeseen outages, both with the database and with the platform, all decision-makers at the District will receive an immediate email from their Customer Success Manager outlining the problem, any anticipated impacts, and an approximate resolution time, if it is known. After this initial email, the Customer Success and Product teams working with the District will keep the District continuously updated on progress toward a resolution via email until the issue is resolved.
Non-Source and Source Code
Since Grow is a cloud-based platform, all updates and code changes are automatically deployed to the application at regular intervals with no need for end-users or the District to download or install any upgrades. Grow works on a standard Agile two-week sprint cycle, where our tech team works on bug fixes, general updates, enhancements, and quality assurance throughout the two-week period, and releases are pushed to end-users every other Friday. There is no downtime and no interruptions when releases are pushed, and when users visit the site next, they automatically see all changes. Typically, these two-week updates are incremental in scale. If larger-scale changes are planned or anticipated, these are communicated directly to the District by their Customer Success Manager with a longer lead time to allow for preparations. Additionally, at rare times, Grow may push bug fixes outside of the two-week cycle if a bug is determined to be critical to the end-user experience. These situations will also be communicated to the District, and users will also experience no downtime when these hotfixes are pushed.
How are enhancements prioritized across clients?
The majority of Grow enhancements are general updates applicable to all of our partners. These are released to all clients during the two-week sprint process outlined above. When enhancements are requested by specific clients, our first priority is to try and make the enhancements applicable to all partners, in which case the enhancement will go out to all partners at once. If something is unique or specific to one partner, the Customer Success Manager (CSM) working with the partner and a member of the Product team will have a conversation with the District around the District’s priorities and internal timelines, and determine feasibility on a case-by-case basis.
Do you need more information?
Click the Support and Feedback button or email us at firstname.lastname@example.org