Hi all
Our organisation has been on a journey with Monday the last couple of years, in which we slowly expanded it from a project management system to a full WorkOS, which handles everything from CRM, Resourcing, Projects, Finance, etc.
I am finishing up in my role with the organisation soon, so I had to write a guide for the incoming Monday Admin who is replacing me. I wanted to share a small excerpt of the content of the guide with this community, in case it’s useful to anyone else.
I have previously made other posts with more detail about some of the challenges I have encountered in designing our Monday framework - see my post history if you are curious. But essentially, things got messy and chaotic as it grew and evolved, which led me to blow everything up and start again from scratch with a clean, elegant design a few months back. Going forward, these are essentially the principles by which we now live in Monday. Apologies if it’s a bit hard to follow - I wasn’t able to do nested headings so the hierarchy is probably a bit unclear, but hopefully you get the gist.
Design principles for our Monday environment
The following principles guided the design of our Monday environment. As you continue to build and maintain the environment, please keep these principles in mind.
Follow database normalisation rules
The first and most important principle for Monday is that the design should conform to database normalisation rules where possible.
Normalisation is the process of organising data in a database. This includes creating tables and establishing relationships between those tables according to rules designed both to protect the data and to make the database more flexible by eliminating redundancy and inconsistent dependency.
Redundant data should be avoided because it wastes processing time and storage space and creates maintenance problems. If data exists in more than one place, this creates extra work because the data must be changed in exactly the same way in all locations. For example, a change to a project’s name is much easier to implement if that data is entered only in the Projects board and nowhere else in Monday (any other appearances of the project name should be a mirror column from the Projects board, rather than entered manually).
Inconsistent dependencies should be avoided because they can make data difficult to access, because the path to find the data may be missing or broken. For example, while it is intuitive for a user to look in the Projects board for the deal value of a particular project, it may not make sense to look there for the postal address of the partner who referred the project. The partner’s address is related to, or dependent on, the partner, and thus should be moved to the Accounts board.
Each rule of database normalisation is called a “normal form.” If the first rule is observed, the database is said to be in “first normal form.” If the first AND second rules are followed, the database is said to be in “second normal form”.
As with many formal rules and specifications, real world scenarios do not always allow for perfect compliance. In general, normalisation requires additional tables and sometimes this can be cumbersome. If you decide to violate one of the rules of normalisation, make VERY sure that your design anticipates any problems that could occur, such as redundant data and inconsistent dependencies.
First normal form
-
Eliminate repeating groups in individual boards.
-
Create a separate board for each set of related data.
-
Join related data with a Connect Boards column.
Do not use multiple fields in a single board to store similar data. For example, for a project whose funding may come from two possible funding sources, an item could contain fields for Funding Source 1 and Funding Source 2. But what happens when you add a third funding source? Adding another column is not the answer; it requires program and table modifications and does not smoothly accommodate a dynamic number of funding sources. Instead, place all funding source information in a separate table called Funding Sources, then link Projects to Funding Sources with a Connect Boards column.
Second normal form
-
Create separate boards for sets of values that apply to multiple items.
-
Relate these boards with a Connect Boards column.
Items should not depend on anything other than the item name. The item name should be the unique key for each item. For example, consider the Project ID. The ID is needed by the Projects board, but also by the Tasks, Budgets, Quotes, Invoices, and Purchase Orders boards (and probably others too). Instead of storing the project ID as a separate entry in each of these boards, store it in one place, in the Projects board.
See here for more information on database normalisation: Database normalization description - Office | Microsoft Learn
Build only what is necessary
There should only be as many boards and workspaces as strictly necessary, without violating database normalisation rules. Boards should only have as many columns and views as strictly necessary. If you create a new board, it will come with some template columns (person, date, status). Feel free to delete these unless you are definitely going to use them for meaningful data that you will need to store or gain insights from.
Choose column types wisely
Monday has a vast array of column types, and the type you select will govern what you can do with that data. Familiarise yourself with the options here: https://support.monday.com/hc/en-us/articles/115005310285-What-are-the-column-choices-. It’s especially important for you to get your head around the difference between a one-way and a two-way Connect Boards column, and the difference between a Connect Boards and a Mirror column. This can be confusing initially, but our environment uses them a lot, and getting them mixed up can cause everyone a lot of headaches.
Some column types may seem like a logical choice, but will constrain you later. For example:
-
While the same purpose can usually be achieved with either a status column or a drop-down list, many more automations can act on a status column than on a drop-down list.
-
Creating a text field and putting numbers in it will prevent Monday from recognising those numbers as such, and will not allow you to do things like sum the total of the column or use the column in a formula.
-
If you plan to use data in one board to automatically create connected items in another board via an automation, there are certain column types for which this is not supported. For example, formula columns, Connect Board columns, and mirror columns. Think about how and where you might need to use the information in that column when you create it, and choose the column type accordingly.
-
Be aware that the values of Formula columns, Connect Board columns, and Mirror columns cannot be accessed by the API (in the sense that the API cannot read the data in these columns). This is relevant if you plan to, for example, connect an app that does an automatic backup/restore, or connect data in Monday to another external application using an integration.
Name everything clearly
Every board, group, and column should be labeled in a way that the user can clearly discern its purpose. Do not use acronyms, initialisms, or abbreviations (even if it means that the whole column name cannot be seen without hovering over or expanding the column). When naming boards, groups, and columns, put yourself in the user’s shoes and think about the most logical name to give it based on how they will use it or what it represents to them.
Minimise governance with automation
Workflows in Monday should be intuitive, and require as little manual intervention by an administrator as possible. Regular manual data entry should be as minimal as possible, and everything that can be automated should be, in as few steps as possible. Manual transferring of information from one place to another should be avoided where possible by using a combination of Connect Board columns, mirror columns, and automations so that it shows up where people need to see it without them needing to re-enter it or look in multiple places. Where data cannot be connected with Connect Board or mirror columns, use an integration such as Vlookup Autolink to make sure that changes in one place are reflected in the other and replicated data does not get out of sync.
Familiarise yourself with automations here: https://support.monday.com/hc/en-us/articles/360001222900-monday-com-Automations
Keep the live environment clean and fully functioning at all times
If you are in the process of building something, make sure it is not seen by anyone until you have fully tested it and communicated it to the users. To prevent users from seeing half-built things, you should try any of the following:
-
Create a private test board with the same columns as the real board. Create sample data in it. Only when you are satisfied that everything works and you are ready to communicate it, THEN implement the changes on the real board.
-
Do not duplicate boards that have connected items and then make the duplicated board private for your testing. This will cause the connected columns in the original board to disappear for any users who do not have access to your private workspace. If you do this accidentally though, you can resolve it by going to the original board, finding all the connected columns, and disconnecting the duplicate board. Make sure you don’t disconnect the board it’s meant to be connected to, because this is irreversible.
-
Hide the column using View or Edit restrictions, or make sure it is only showing in the Main Table and not any other views that users regularly use. Note that the latter involves going through every view on the board and manually unchecking any newly created columns.
-
If you created test data or columns that are not strictly necessary in the process of building, delete them as soon as possible so that only usable columns and legitimate data remain in the live board. If a temporary column has to stay on a board for more than a day and it must be visible to users, make a post in the Monday.com users space to let everyone know what it’s doing there and when it will be removed.
Keep documentation up to date
It is absolutely crucial that this documentation is updated every time something is added, deleted, or changed about the Monday design. This is the only way to avoid “key man risk” - in other words, ensuring that someone other than the person who made the change knows what the design looks like and how it should work. It also reduces your workload if you can refer users to accurate documentation instead of spending time explaining how to do things.
