Often, making a change to an application can look pretty straightforward from the outside. Without understanding the underlying structure of the application, it can be hard to realize how much functionality it touches.
At Agrilyst, we recently decided to make a change in how we structure users, organizations, and facilities. Originally, user accounts were associated with one organization. Each organization could be associated with multiple farm facilities. Let’s say you operate two distinctly different farm locations: one greenhouse named Starkiller Base in California and one R&D Demo facility in Toronto. In Agrilyst, you can create one organization for your group (we’ll call it Jamey’s Adventures in Farming) and simply add each facility to your organization.
This allows the user to switch between facilities and keep data separate for each. Since organizations could have multiple facilities, it seemed like one organization would be enough for the average farmer — even if they were overseeing multiple farms, they could have a facility for each one and they could still all be contained underneath a single umbrella organization. Simple.
Recently however, we’ve had a few users who we’ll categorize as: franchise farms (we recognize that folks aren’t necessarily creating a real franchise). These folks are owners of a parent company who sell farm systems as a whole. One of our customers in this category is Indoor Farms of America. They sell farm systems for containers, warehouses, and greenhouses. Each farm they set up is its own facility, but it belongs to a separate organization as well. Now we’re talking about multiple organizations each with their own facilities. Having users try to use the site in an unintended way is a really exciting thing because it’s a very clear indicator of their needs and what we can do to improve the platform.
So how do users play into all of this? These franchise farms often work with their various organizations to help them during their early stages of operation and growth. Imagine opening up a new farm and having no knowledge of what to do when something goes wrong. Instead, in the franchise farm model, the parent company is there as a semi-consultant to help growers understand what to do whenever there’s a question. Now imagine the parent company gets access to each organization’s dashboard (with their permission) so they can predict things ahead of time as well as find ways to improve real-time.
We loved that idea. So we decided to change our organization structure so that users can be associated with more than one organization within Agrilyst.
This may not seem like a huge change. In fact, from the perspective of a user on the front-end, the updates are extremely minimal. If a user has access to more than one organization, the facilities they can view are still listed on the facility dropdown, but they are sorted by which organization they belong to.
To keep it simple, even adding someone new to your organization works exactly the way it did before. The form below originally functioned only to send out an email invitation to create a new user account. Now, in addition to that, it can also detect if the email you entered already has an existing Agrilyst account. If an account already exists, Agrilyst will create an association directly between the existing user and your organization. And the user interface didn’t change at all!
So from the user side, it’s barely noticeable if you’re not looking for it, but the change to the back-end codebase was pretty major! The user and organization structure really existed as part of the backbone of the application, so updating it touched a lot of different functionality, and was integrated very tightly with user registration and how we determine what facility should be active for the user. Organizational settings are tied up in this, and so are user roles, since now a single account can have separate roles for the different organizations they belong to (which means you can be a Grower at Organization A but only an employee at Organization B, and that affects what you can view and edit in the system).
It’s important to always keep in mind the potential disconnect between the appearance of change on the front-end of the application and the level of interconnectedness of the same feature on the back-end. Always being aware of how different pieces of Agrilyst integrate with and affect each other gives us confidence that updating the site to better serve our users won’t cause any unforeseeable issues elsewhere — which means more new features without risking any of the current functionality, which makes Agrilyst what it is, or disrupting the work of the growers who rely on it.