Inspiration

I got inspired by the number of messages in both the Community and the Partner channel where fellow monday.com lovers are asking for this kind of solutions. Although the amazing dashboards in monday.com will solve parts of the puzzle, it is not possible to rollup information through different levels. There is more to retrieving information out of data. I came across many organizations that need to rollup data (like costs, status, timeline etc.) through a number of levels (e.g. department - region - global). That is why I developed Master-Detail Boards.

What it does

Rollup Multiple Boards (RMB) gives you the possibility to create new boards from monday.com account templates. You can build different templates for different project types and still rollup information to a higher level. This higher level board can roll up information further up in the pyramid. The hierarchy of boards is maintained in a database that does not contain any of your important board data. The database only stores data like boardIds and columnIds. To add monday.com templates to RMB hierarchy use the recipe:

When this status changes to this value create a board based on this template. Name the new board as "item name - status value" and place link in this column.

When you change the status column to the value specified a new board is created and the relationship between the new board and the board that created it is maintained in a database. You can create as many boards as you need.

All other recipes are configured to watch for changes in all the created boards. The board where you created the "detail" boards from (let's call it the "master" board) will receive events when changes occur in any of the board under direct control. The board on itself can be under watch from a higher level board, creating a real hierarchy of boards. The recipes aggregates data from all items and condense the information in one item. You can chose to see the sum, the average, the minimum value, the maximum value, the earliest date, the latest date, the total time spent or the percentage of status with a given value (percentage of completion). An example of such recipe is:

Watch this number in connected boards and aggregate detailed board items to this column, displaying the operation.

Recipes like this are available for number, status, timeline and time tracker columns (more to come). There is another recipe available to set a status (using the RAG model) in the Master boards based on the statuses in the Detail boards. This Red-Amber-Green status gives an immediate (and live) overview of the health of all underlying projects.

The output columns that hold the aggregated data from the underlying boards are plain monday.com columns and can therefore be used in formulas or other automations. Subtract the actual cost from the budgeted cost and alert someone if there is more that 15% overrun. Divide the actual cost by the actual time spend and guard your daily rates.

Is some (or all) data in the project boards coming in externally (form other software or from form submissions). Next to changes of existing data new data coming in generates events that triggers the recalculation. You are always up-to-date and on top of your business!

How I built it

The app / feature is built with node.js that runs an a Plesk server on Ubuntu. On the same server a mariaDB instance is running to store the hierarchy of boards. On the monday.com side I am use custom triggers and custom actions. The main reason to use custom triggers is that I use the subscribe event to check (or create) a purchase record in my database. The purchase record contains the installation date and a notification date. Newly installed features will be available in trial mode (currently set to 10 days). This trial mode can be unlocked from the Excellent Team web shop.

The core of each "master" board is the "Collector" endpoint which receives all requests from column changes and item additions from all connected lower level boards. The "Collector" will post requests to the configured recipes based on the column type that is under watch. This triggers the action part of the recipes to post to a recipe specific endpoint that does the aggregation and set the outcome in the desired column in the "master" board.

Basically the "Collector" sits between the webhooks in the connected lower level boards and the actions of the configured recipes in the higher level board.

Challenges I ran into

The main challenge is with custom field type (dropdown boxes). It would be very helpful to have dependencies between different custom fields. The way I envision that is that a user first needs to select FIELDA and that the call requesting the values for FIELDB has the selected value of FIELDA in its payload. In that way the app can show exactly the values to choose from.

Accomplishments that I'm proud of

The two accomplishments I am most proud of are:

  1. The idea to have a common endpoint "Collector" that sits in between all inserted webhooks in the lower level boards and the action part of the column based recipes in the higher level board.
  2. The implementation of a trial mode for all features and apps (with the unlocking feature through our shop).

What I learned

I learned the most from an earlier version of this app that was too difficult for the average user to set it up. It shows that users want to see recipes they immediately understand without reading any document about how to make it work for them.

What's next for Master Detail Boards

  1. more narrowed choices in dropdown boxes (need custom field dependencies for that)
  2. more column types (dropdown, date and people columns are under development)
  3. switch to seamless authorization when it becomes available (use temporary tokens)

Built With

Share this project:

Updates