monday.com production scheduling for job shops and fabricators: what to build and where it stops

Yes, for the kind of manufacturer whose scheduling problem is mostly about seeing and handing on work. A fabrication shop, a joinery, a kitchen or furniture maker, a sign maker or a trailer builder typically has tens of jobs in flight. Each one is different, each passes through some or all of the same stages, and a few people or crews do the work. The questions asked every morning are where each job is, who has it, whether it will be finished by the date the customer was given, and who is overloaded next week. monday.com answers those well. A job is a record moving through stages with an owner at each step, which is exactly the shape of work our comparison of monday.com and Asana says monday.com is built for.

Where it breaks is calculation across jobs. monday.com works out values one item at a time. Dependencies shift one job's dates when an earlier stage slips, and the Workload view shows a person going over capacity. Neither decides which of two clashing jobs goes on the welding bay first, and nothing on a board knows that a job cannot start because its material has not arrived. Sequencing against finite capacity, bills of materials, material requirements and stock are ERP territory, and the later sections say where that line sits.

Most of what follows comes from fabrication work. The longest engagement is with a fabrication business in New South Wales, Australia. It began with a fixed job to mirror and move a sales board between private boards, and became a 222-hour engagement over 19 months. The brief at the start was status and date automations driven by formula columns, carrying each job through four stages: To Assemble, To Weld, To Send and Sent. It grew into ongoing build and support on the same account.

A second fabrication company, in a separate engagement, asked for an automated production-scheduling workflow on monday.com. It had to show each job's stage, owner, projected finish date and man-hours, flag overlapping jobs and staffing gaps, and notify the next responsible person automatically. The contract was completed and reviewed.

For a manufacturer in Queensland, the brief was to take a basic job-management project on monday.com and refine it into a production schedule for jobs moving through the factory. We have also set up weekly timesheets on monday.com, and we have built ERP, CRM and project-management systems for businesses in the furniture industry, where kitchens, cabinetry and joinery follow the same job-shop pattern. At the sales end of a manufacturer, our Make work for a trailer manufacturer files each handover pack on the invoice in Xero and releases a unit only once that invoice is paid. That is not a monday.com build, and it is not a schedule. It is here because a production board always has neighbours, and the money and the paperwork usually belong to them.

Decide what an item is before there are three hundred of them. Our rule on monday.com is that one item is one unit of work that one person can own and close. In a job shop that leaves three workable models, and the right one depends on the question you need the board to answer.

Our default is the first model. It is the easiest for a shop floor to read and the hardest to break. Move to the third when someone asks how many welding hours are booked next week and needs the answer per person. We rarely use subitems as stages for capacity work, for the reporting reason above.

The columns that matter on a job

• A job number that never changes. Integrations, timesheets and the accounting system all key on it.
• The promised date, entered once and not moved by automations. Projected finish goes in its own column, so the gap between the two is visible.
• A Stage status with one meaning: where the job is. Blocked and QA failed go in their own columns, not in Stage.
• One People column per stage owner, so the handoff recipe knows whom to notify.
• Estimated hours per stage as Numbers columns, and actual hours from a Time Tracking column (a Pro feature) if you want estimate against actual.
• A helper date per stage, written by an automation when the job enters it, so you can see how long jobs sit at each handoff.
• A connection to the customer or order record, if those live on another board.

With a formula column, within limits that monday documents. The functions you need exist: TODAY() gives the current date, ADD_DAYS adds days to a date, and WORKDAYS counts the working days between two dates, using the working week set in the account (Monday to Friday or Sunday to Thursday). A projected finish usually works like this: add up the estimated hours for the stages not yet done, divide by the hours the crew works in a day, and add that many days to today.

The catch is that ADD_DAYS adds calendar days. monday's Help Center documents no function that adds a number of working days to a date. So a shop either schedules in calendar days and accepts that weekends are counted, divides by a seven-day week of hours to compensate, or works the working-day date out outside monday.com and writes it back to the board. For a shop promising dates to customers, the last option is the honest one.

The formula trap

monday's Help Center states that a formula column is read-only and cannot trigger an automation. Its output is also not always recognised by automated emails, notifications, chart and dashboard widgets, or cross-board actions such as mirroring. A recipe written as when projected finish passes the promised date, notify the planner will simply never fire. monday's own workaround is to copy the formula result into a regular Numbers or Text column with a workflow, and point the automation, email or widget at that column instead.

This matters more in production scheduling than almost anywhere else, because the logic people want to automate is calculated: days late, hours remaining, the next stage. The fabrication brief above was status and date automations driven by formula columns, and that is exactly where this limit applies. Whatever carries the value across (a monday workflow, a Make scenario or a small service), the recipe has to watch a real column, and the copy has to be refreshed whenever the inputs change.

Dependencies and the Gantt view

On the stages-board model, the Dependency column links one stage to the next. monday supports finish-to-start, start-to-start, finish-to-finish and start-to-finish links, and three modes: Flexible, Strict and No action. Strict mode also allows lead and lag. Change a predecessor's date and its dependants shift according to the mode, and dragging a bar on the Gantt or Timeline view moves its dependants with it. According to monday's Help Center, dependencies are on Pro and above, the Gantt view and widget on Standard and above, and dependencies across project boards on Enterprise.

Dependencies move dates by logic, not by capacity. If welding on one job runs two days late, that job's dispatch moves. Nothing moves the three other jobs queued for the same welder. That is the difference between a dependency chain and a finite-capacity schedule, and it is the first thing a growing shop notices.

The handoff is where monday.com earns its place in a workshop. When the fitter sets a job to To Weld, the welder should hear about it without anyone walking across the floor. Native recipes do this well, as long as each one has a single trigger with a single meaning. These are the ones we use on production boards.

Count before you build. monday counts actions, not recipes, and a board with five recipes on every job uses five or more actions per job per stage. Rescheduling a week of work with a bulk edit runs every watching recipe once per item, and can notify a dozen people about handoffs that did not happen. Our article on monday.com automations covers how the allowance counts, and the rule from it applies here: one recipe owns each column, and the recipes that watch a column are switched off before a bulk change to it.

Use the Workload view for man-hours against capacity. On 21 October 2026 monday's Help Center described it as available on the Pro and Enterprise plans; check the pricing page for your account. You choose a People column as the resource and measure effort either by counting items or from a Time Estimation, Numbers or Formula column. Where two people share an item, the hours are either split between them or counted in full for each. Each person gets a capacity, monday's own example being seven hours a week, and admins can give users work schedules with working days, hours and time off. Bubbles coloured by load show who is over or under capacity, and clicking one lists the jobs behind it, so the planner can reassign or move dates from there.

That covers per-person load. It does not cover clash detection. A formula column sees only its own item, so it cannot tell that two jobs need the same welder on the same days, that next week's booked welding hours exceed the welders rostered, or that a stage has no owner at all. Those are calculations across jobs. The production-scheduling brief above asked for exactly these flags, overlapping jobs and staffing gaps, and listed Google Sheets and monday's API alongside the board. That is the usual home for a cross-job calculation: a scheduled job reads the board, works out the overlaps per person or per week, and writes a flag column and a notification back where the planner looks.

Machines and bays are a further step. The Workload view plans people. If the constraint is a press brake or a paint booth, we give the stage a Bay column and total booked hours per bay per week, either in a dashboard chart or in the same scheduled job that computes the flags. Either way it is a check, not a schedule.

Build the dashboard from the questions asked at the morning production meeting, not from the widget list. These are the ones that recur in job shops.

• Jobs by stage: how many are waiting at assembly, welding, dispatch. A chart grouped by the Stage column.
• Jobs projected late: projected finish after the promised date. This needs the copied value, not the formula, because widgets do not always read formula output.
• Hours booked against capacity this week and next, per person, from a Workload widget.
• Jobs sitting at a handoff longer than they should, from the helper dates.
• Throughput: jobs reaching Sent per week, which is the number that tells you whether the schedule is improving.
• Flags raised by the cross-job check: overlaps and unstaffed stages, as a filtered list.

Keep the reporting on as few boards as you can. Dashboards slow down as mirrors multiply, mirrored numbers need a formula to total, and formula results often have to be copied into a regular column before a widget will show them. If the dashboard needs a number aggregated across three boards of relationships, monday.com is being asked to be a database, and our monday.com platform page explains why that ends badly.

monday.com stops where production scheduling stops being about visibility and becomes about calculation and materials. This is where we draw the line.

When the bottom rows become the requirement, the default answer is to buy an ERP, and for most small manufacturers that is right. A custom build is warranted only when the valuable part is your own rules: approvals that gate the numbers, documents that must agree with the table beneath them, branches that must each see only their own work. On our trading ERP build, stock quantities move only when a person confirms a captured purchase invoice, and every change is attributable. Our custom ERP development page sets out how to tell whether you are one of the few businesses for which building beats buying.

The common middle ground is a hybrid. monday.com stays the floor's schedule, because people will update it, and the accounting system or ERP stays right about money and materials. The trailer manufacturer's release step shows the pattern from the other side: the paid invoice in Xero is the gate, and an automation watches for it rather than anyone keeping a list. One system is allowed to be right about each object, and the other holds a read-only copy keyed by its ID.

Production boards fail in predictable ways, and most of the failures are structural rather than technical.

A stage column that also means blocked and QA failed

It starts as the stage, then gains On hold, Waiting on material and Failed QA. Now the handoff recipe cannot tell a job going forward from one going back, and the jobs-by-stage chart cannot say what is actually in progress. Keep Stage for where the job is, and give blockers and quality outcomes their own columns.

Recipes watching a formula

The late-job alert that never fires, the projected date that shows as blank in an email, the chart that reads zero. All three are the formula limit above, and all three fail silently. Copy the value into a regular column and test the recipe against it before go-live.

The floor does not update the board

A schedule is only as current as the last status change. If welders have to find a desktop to move a job on, they will do it at the end of the day or not at all, and every date on the board becomes fiction. Put the status change where the work happens: a tablet at the bay, a form, or a page that shows each person only their own jobs and writes back to the board.

Rescheduling by bulk edit

Moving a week of jobs in one go fires every recipe that watches the changed columns, once per job: notifications to the wrong people, helper dates overwritten, and a slice of the month's actions gone. Switch the watching recipes off first.

Automations owned by the planner who left

Recipes belong to the user who created them and are deactivated with that user. A production board built by one planner stops handing jobs on the day their account is switched off. Set a default automation owner when the board goes live.

Nobody agreed who supports it

A board the workshop runs on is production infrastructure. When a recipe breaks, jobs stop moving, and waiting days for a fix costs real output. We have learned that the hard way on a support arrangement that was never written down.

So agree response times for a production board before it goes live, and train someone in the business to own the recipes, so that a broken handoff is a five-minute fix in-house rather than a wait.

1. 01Write down the stages a job actually passes through, in the words the floor uses, and who owns each one. That list is your Stage column, and its labels are an interface that recipes will bind to.
2. 02Choose the model: one item per job for visibility, a connected stages board if you need per-person man-hours by stage.
3. 03Add the columns: job number, promised date, Stage, an owner per stage, estimated hours per stage, helper dates, and projected finish as a formula.
4. 04Decide how the projected finish will be copied into a regular column, and which tool will do it, before writing any recipe that depends on it.
5. 05Build the handoff recipes, one per stage, each notifying a named person. Set a default automation owner.
6. 06Set capacities and work schedules, and add the Workload view. Check the plan: on 21 October 2026 the Workload view, Formula column, Time Tracking and dependencies were Pro features in monday's Help Center.
7. 07Decide where clash and staffing-gap flags are calculated, and where they are written back.
8. 08Put status changes where the work happens, then run the board alongside the old schedule for two weeks before trusting it.
9. 09Agree who supports the board, and how quickly.

Where it breaks: if the shop's real constraint is machine time or material, not people and handoffs, a better board will not fix it. That is a scheduling engine or an ERP, and the earlier section says how to tell.

A disclosure. Skofi is paid to design monday.com boards and automations, to build the integrations around them, and to build custom systems when a board is not enough. We are not a monday.com partner and hold no certification or reseller arrangement with monday.com. The reviews quoted here are from our Upwork profile, where on 21 October 2026 we were Top Rated with a 100% Job Success Score across 114 jobs and 1,925 hours. Not every review is five stars, and one that is not is quoted above.