We have an update on our Test Server that we're planning to deploy tomorrow (Saturday March 28, 2026 at 8PM MST).
If anyone interested in playing with it, feel free to test. We will be creating a more detailed list of updates with screenshots and more complete descriptions when we release.
Hyperlinks
Who's Here / Follow User
Workspace Settings Expansion
Reports Enhancements
Search Improvements
Notes Tool Enhancements
Takeoff Worksheet Overhaul
Sidebar Updates
Offset & Array Commands
Lock/Unlock Objects
Bug Fixes
Performance Improvements
UI Polish
Thank you for all your feedback to help us make zzTakeoff better ππ
Now I'm going to skip how amazing all this stuff is and dive into the direct feedback.
1) Hyperlinks only show up on the default layer.....so sad they don't all transfer thru. I was hopeful as a workaround I could duplicate the default layer, but they don't follow....noooooo. Need a workflow to transfer all hyperlinks to layer asap.
2) When in my templates, I want to batch convert all my existing "one" assembly takeoff's to items.
5min link of me kicking things LINK
Canβt wait to check out assemblies. Lots of great updates. Happy about targeted page search. Thatβs a good start to bring able to search and count/highlight feature. Iβm really excited π₯ about takeoff window on a side monitor while QTO. Text scaling sounds like a legit tweak - TY. So many fun things to try next week. Enjoy the weekend!
Yes we can KILL the decimals now, sweet! One minor problem right now is there are still decimals in linear takeoffs and items

Thanks for the input π Yeah, we'll have to figure out how to make those hyperlinks go to all layers. We'll check on that decimals setting to make sure it's properly applying to the right sidebar.
I'd say this is the biggest problem with having the takeoff parent also be the takeoff item is it is super confusing for the UOM. Need to make this more clear! Here is a 2 min vid on this topic.

If you're building assemblies, most users should not use takeoffs that are also items. The cleanest path is to build the parent takeoff (which is already an assembly by default) and add child items to it. They will total up nicely, etc. Using a takeoff that is also an item is primarily for users that don't use assemblies at all. Mix/match is possible, but not the intended use. There may be some ways of using this that we haven't thought of yet, though. We're listening, and also discussing internally.
For the most part, you don't want a takeoff that is also an item having child items. You would want the parent to be an assembly so it totals up its children, etc. This is our first iteration with this feature, so we'll be for sure adding more safety guards and simplifying things as we go.
EDIT: Another thing I want to clarify for any new users reading this: on the live server (before this update) all current takeoffs are already assemblies. With this new update a takeoff can be either an assembly or an item. Most of the time takeoffs should be used as assemblies.
@Kyle
So for example what if the workflow involve a top-level LF takeoff driving a nested assembly? I would want to ensure that a single LF input at Level 1 can correctly scale Level 3 sub-items that require different units (EA, SF, and LF) within that same template. Which I know we all do. Are you just saying the default should inherit the top level qty/UOM?
@Heber,
100% agree with your logic for detail trades work takeoffs AKA selfperform work. Parent - Item. setup that we are rolling with and its a great setup. Was heading this direction for our GC takeoffs too, but every parent would need a item which is confusing for the user.....so low and behold you dropped this update that's getting soooo close.
My problem (that this is getting close to solving) is I'm trying to find the best work-flow for our "GC" estimate people. Most of what we need is only one single parent item so I want a SIMPLE workflow for that.....but there are cases when it make sense to make a assembly for this "GC" Takeoff.....now that we are mixing and matching its confusing now. I feel like the auto-inherit the measurement qty/uom is the final tweak we need.
@Chaz - Yeah, Inherit the top level MEASUREMNET for qty/uom when using a parent takeoff as a item.
Might be an issue with the list items?
I kept getting this error. Ended up just clicking on the new fancy "Convert to Item" button

